A few minutes ago, the ISO C++ committee completed its autumn meeting in Belfast, Northern Ireland, hosted with thanks by clearpool.io, Archer-Yates, Microsoft, C++ Alliance, MCS Group, Instil, and the Standard C++ Foundation. As usual, we met for six days Monday through Saturday, and we had about 200 attendees. We now have 23 active subgroups, most of which met in nine parallel tracks all week long; some groups ran all week, and others ran for a few days or a part of a day, depending on their workloads.
See also the Reddit trip report, which was collaboratively edited by many committee members and has lots of excellent detail. You can find a brief summary of ISO procedures here.
C++20 is on schedule to be finalized in February
Per our official C++20 schedule, at our previous meeting in July we reached feature-freeze for C++20 and sent out the C++20 draft for its international comment ballot (Committee Draft, or CD) which ran over the summer and generated 378 comments from national bodies.
At this meeting and the next one (February in Prague), our main job was to work through these comments as well as other fit-and-finish work for C++20. To make sure we were in good shape to finish in Prague, our goal was to make sure we resolved at least half the national body comments at this meeting. Thanks to a lot of hard work across all the subgroups, and especially the subgroup chairs who leveraged our ability to do work in parallel in our nine tracks and domain-specific subgroups, this week we resolved 73% of the national body comments, and made good progress on most of the rest. Here’s a snapshot of national body comment status, breaking out the number that we were able to close even before the end of the week, and the number of CWG (core language) and LWG (standard library) comments whose final resolutions we adopted today:
This means we are in good shape to ship the final text of the C++20 standard at high quality and on time, at the end of the next meeting in February in Prague.
Because we are in feature freeze for C++20, no new major proposals were added into C++20 at this meeting, though we did adopt a few minor design fixes. Most of the changes made at this meeting were bug-fix level improvements, mostly to the “wording implementation details” to make sure features were specified correctly and clearly in the formal specification wording to implement the approved design.
Other progress
In addition to C++20 work, we also had time to make progress on a number of post-C++20 proposals, including:
- the new SG21 (Contracts) study group’s first meeting;
- the newly reopened SG4 (Networking) study group including an evening session on networking security;
- an evening session on executors;
- further progress on reflection and compile-time programming proposals;
- progress on pattern matching in the main language evolution design group;
- and much more.
Thank you again to the approximately 200 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Our next step is to finish the final text of C++20 three months from now in February (Prague, Czech Republic) and then send final C++20 out for its approval ballot.
Sutter’s Mill 
@jmckesson in the last cppcast[1] Timur Doumler says: “we didnt get the library part in, but we might get the language part in which is going to unUB a lot of code” about P0593. Seems promising.
[1]https://cppcast.com/timur-doumler-belfast/
@Herb, I might be jumping in, from outside, but I dare to ask: ISO C++ committee, I assume, has some established system for categorizing and prioritizing the “Requirements” for the lack of better word? Something like this perhaps: http://www.jot.fm/issues/issue_2004_09/column4/ .
@jmckesson: I should have added that I didn’t bring updated versions of any of my proposals for this meeting because we were focused on C++20 and they are progressing well via other papers or other progress.
Metaclasses relies on reflection and compile-time programming as prerequisites — most of the P0707 paper was about getting those two things, and they are now being carried forward by complementary papers by a variety of authors (including the primary metaclasses implementers, Andrew Sutton and Wyatt Childers), and are making progress at every meeting. Metaclasses are then just a syntactic sugar over those, and while those underlying facilities are being developed my main work in this part of language evolution is to make sure they stay on track to be able to build metaclasses on top easily (and it’s all going fine).
Static exceptions is primarily gated on getting implementation experience to generate data, so I’m waiting primarily for that before bringing another major revision. In the meantime, though papers are still progressing well, such as Niall’s and others’ proposals for the std::error type and Ben Craig’s Belfast evening session on exception performance. I may also break out the OOM-related parts of P0709 to make progress independently, either as a separate paper or by updating and presenting just that part of P0709 in Prague or Varna.
While I agree that contracts is very important to fixing exceptions, I don’t agree that not having them in C++20 is a “fatal mistake”. It’s better to have the *right* kind of contracts than to have a bad version of the feature, and the feature C++20 was getting had accidentally drifted into a bad place. Better to stop and reassess what contracts are actually supposed to mean (there was contention around this point) than to ship a broken contract feature.
Besides, so long as contracts and static exceptions are available at the same time, the problem can effectively be dealt with.
Exceptions “fixing” is very important, but contracts are the key for unlocking the dusty gate to C++ error handling, unopened for 30+ years. Not having that in C++20 is a fatal mistake.
There’s not really much to talk about, since most of the big stuff was already done, but I have some questions.
First, reports seem conflicted; did P0593’s core language changes make it into C++20 or not? There was a national body comment about it, but it’s unclear how that worked out.
Second, how did your revised version of static exceptions go over with the committee? Did you present it, and if so, how well was it received?