Belfast resolves most C++20 ballot comments
The November meeting resolves 73 percent of national-body comments, with the remaining work centered on specifying an already selected feature set.
Feature freeze establishes which capabilities a language revision intends to provide. It does not establish that every interaction has sufficiently precise wording. Herb Sutter's November 9 Belfast report describes that second phase of C++20. The international comment ballot produced 378 national-body comments, and the meeting resolved 73 percent of them.
The meeting's goal had been to resolve at least half. The report says work also progressed on most of the remaining comments. These figures describe comment resolution, not a percentage of compiler implementation or a count of features completed. Keeping that distinction matters when interpreting the status of a standard.
I find this stage particularly relevant to C++ because the language's difficulty often lies in interactions between individually familiar facilities. A concise feature summary can explain its intention while leaving questions about lookup or lifetime unanswered. The formal wording is where implementations need a shared answer.
The schedule separates selection from specification
The October schedule paper P1000R3 distinguishes design completion from completion of the Committee Draft wording. It places national-body comment resolution after the draft goes to ballot. Belfast's work follows that sequence.
This is a useful separation of deliverables. A design can have committee agreement before every clause needed to integrate it has been reviewed. Wording review translates the intended behavior into requirements that fit the rest of the language and library.
Sutter reports no new major C++20 proposals adopted in Belfast. The meeting made minor design fixes and changes described mainly as wording implementation details. That does not make the work inconsequential. A correction to the conditions under which a program is well formed can matter to source compatibility even when it does not receive a new feature name.
The report does not enumerate every resolved comment in its prose. Its aggregate progress should therefore not be used as evidence that a particular concern disappeared. A specific compatibility claim still needs the wording or resolution associated with that concern.
Modules illustrate why terminology matters
The earlier merged modules paper P1103R3 provides an example of the precision a major addition requires. It distinguishes visibility for name lookup from reachability of semantic information. A declaration can matter to understanding an imported interface without becoming a name the consumer may freely use.
That distinction has consequences for templates. A template can require semantic information about types or declarations beyond the names directly exported for a consumer. Treating all such information as either completely public or completely absent would not capture the design.
A formal specification has to describe where lookup happens and which declarations affect the result. An introductory statement that modules improve encapsulation cannot settle those cases. That is the kind of gap a specification review must be able to find.
This example does not identify a particular Belfast resolution. It explains why a ballot over an existing feature set can still require substantial language work. The subject under review is the exact contract, including interactions with facilities that predate the addition.
Library requirements also need exact boundaries
A library facility combines several kinds of requirement. Some expressions must be valid for a template to participate in overload resolution. Other conditions constrain runtime arguments. A useful implementation and a caller need to distinguish those categories.
A short description of a facility can blur that distinction. Saying a function requires a property does not say whether a bad call is rejected during compilation or violates a precondition at execution. The formal wording determines which question the implementation must answer.
This matters to generic code. A library author may test whether an expression exists and use that result to choose another operation. If the requirement belongs only to a runtime precondition, successful substitution does not establish that every call is valid. Specification precision is necessary to make such reasoning reliable.
I prefer to read a library interface with those boundaries in view. C++'s type machinery can express a great deal, but it cannot make a runtime obligation disappear merely because an expression compiles. Wording that keeps those responsibilities separate improves the basis for both diagnostics and application design.
A fixed revision can coexist with continuing research
P1000R3 explains the committee's fixed release interval. Features can continue developing separately, and a feature that is not ready can leave the draft without delaying the entire revision. That policy separates a feature's development time from the selected revision's completion.
Contracts is the immediate example in the schedule discussion. It had already left the C++20 draft, while the new contracts study group continued its work. Belfast's report records that group's first meeting. Continued discussion did not silently restore the removed feature.
The report also records progress on networking and executors, alongside reflection and pattern matching. These are described as work beyond C++20. A paper discussed in the same week as ballot resolution can therefore have a different target from the draft being stabilized.
That distinction is useful when following committee news. A meeting can make progress on several bodies of work while adopting only corrections into the current revision. Treating every topic on the agenda as part of C++20 would misrepresent what an implementation is expected to provide.
Comment counts have a limited interpretation
Resolving 73 percent of comments is concrete evidence of progress through the ballot workload. It does not imply that the unresolved portion is proportionally small in difficulty. Comments differ in scope, and the report separately notes progress on much of the remaining work.
Nor does resolution mean deployment. A language document can specify a facility before every compiler and standard library implements it. Application adoption still depends on the toolchains that will build the code.
Belfast's supported conclusion is narrower and useful. Most national-body comments have resolutions, the selected C++20 feature set remains under specification review, and work on later capabilities continues separately. For a reader evaluating the revision, that identifies which document is being completed and why the remaining task concerns precise behavior across the language and library.