On Saturday, the ISO C++ committee completed the first of two final fit-and-finish meetings for C++26, in our meeting in Kona, USA. What we have in the C++26 working draft represents exactly the set of features we have consensus on so far; the goal of these last two meetings is to fix bugs and otherwise increase consensus for the C++26 standard. We are well on track to complete our work on C++26 and set it in stone at our next meeting in March 2026.
This meeting was hosted by the Standard C++ Foundation. Our hosts arranged for high-quality facilities for our six-day meeting from Monday through Saturday. We had about 200 attendees, about half in-person and half remote via Zoom, formally representing 21 nations. At each meeting we regularly have new guest attendees who…
On Saturday, the ISO C++ committee completed the first of two final fit-and-finish meetings for C++26, in our meeting in Kona, USA. What we have in the C++26 working draft represents exactly the set of features we have consensus on so far; the goal of these last two meetings is to fix bugs and otherwise increase consensus for the C++26 standard. We are well on track to complete our work on C++26 and set it in stone at our next meeting in March 2026.
This meeting was hosted by the Standard C++ Foundation. Our hosts arranged for high-quality facilities for our six-day meeting from Monday through Saturday. We had about 200 attendees, about half in-person and half remote via Zoom, formally representing 21 nations. At each meeting we regularly have new guest attendees who have never attended before, and this time there were 17 new guest attendees, mostly in-person, in addition to new attendees who are official national body representatives. To all of them, once again welcome!
The committee currently has 23 active subgroups, 10 of which met in 6 parallel tracks throughout the week. Some groups ran all week, and others ran for a few days or a part of a day, depending on their workloads. Unusually, there were no major evening sessions this week as we focused on completing the feature set of C++26. You can find a brief summary of ISO procedures here.
Beyond feature freeze: No new features, one removed (trivial relocatability), and many improvements
We are beyond the C++26 feature freeze deadline, so no major new features were added this time.
This week we heard and worked through concerns about several features, including comments proposing to move features like contracts and trivial relocatability out of C++26 for further work. We resolved 70% of the official international comments on C++26, which puts us well on schedule to finish at our next meeting in March, and we fixed many other issues and bugs too.
Here are a few highlights…
For contracts (pre, post, contract_assert), we spent most of Monday and Tuesday reviewing feedback. The strong consensus was to keep contracts in C++26, but to make two important bug fixes and pursue a way to specify “must enforce this assertion”:
- We discovered two bugs, and adopted fixes for those at this meeting. One was paper P3878R1 “Standard library hardening should not use the ‘observe’ semantic” by Ville Voutilainen, Jonathan Wakely, John Spicer, and Stephan T. Lavavej.
- For the next meeting in March, we are also pursuing something like the first proposed solution in P3911R0 “[basic.contract.eval] Make Contracts Reliably Non-Ignorable”by Darius Neațu, Andrei Alexandrescu, Lucian Radu Teodorescu, and Radu Nichita (though not necessarily with that particular syntax). The idea is to add an option to express in source code that a pre/post/contract_assert must be enforced, which some view as a necessary option in the initial version of contracts. A group of interested persons will work on that design over the winter, including to answer questions like “what syntax?” and “should violations call the violation handler or not?”, and bring a proposal to the March meeting.
Based on the national members’ feedback in the room, these changes appear “likely” to satisfactorily address the most serious national body contracts concerns — fingers crossed, we’ll know for sure in March.
For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26.
For erroneous behavior (EB), we adopted P3684R1 “Fix erroneous behavior termination semantics for C++26” by Timur Doumler and Joshua Berne to tighten and improve its behavior.
- Recall: EB is a new C++26 concept that means “well-defined to be Just Wrong”… any code whose behavior is changed from undefined behavior (UB) to EB can no longer result in time travel optimizations or security vulnerabilities. The first place we applied EB is that in C++26 reading from an uninitialized local variable is no longer UB, but is EB instead.
- Before this meeting, C++26 said that if a program performs EB by reading from an uninitialized local variable, then the program may be terminated immediately or at any later time in the program’s execution; the latter part was problematic and a bit too loose.
- After this meeting, the program can still be terminated immediately, or “soon” thereafter when it actually tries to use the uninitialized value; it cannot just fail ‘sometime arbitrarily later’ anymore. In short, instead of “poisoning” the entire program after an uninitialized local read, C++26 now “poisons” only the specific uninitialized value that was read. This change makes EB much easier to reason about locally and is compatible with what the existing implementations in compilers and sanitizers actually do.
We adopted P1789R3 “Library Support for Expansion Statements” by Alisdair Meredith, Jeremy Rifkin, and Matthias Wippich. It makes integer_sequence support structured bindings, so that the type is easier to use with the “template for” and structured bindings pack expansion language features we added in C++26.
We also adopted P3391R2 “constexpr std::format” by Barry Revzin. This makes it easier to apply string formatting to strings that need to be used at compile time, notably so they can be passed to static_assert which can accept std::string messages in C++26.
And many more tweaks and fixes. Whew!
A new convenor team and secretary
I’ve been serving as convenor (chair) of the C++ committee since 2002 (with a brief hiatus in 2008-09 when P.J. (Bill) Plauger did it for a year, thanks again Bill!). It’s very unusual for one person to serve so many terms, and I’ve been telling the committee for over a year now that it’s time to pick someone else when my current term expires on December 31. Nothing else is changing; I’ll continue to be participating actively in WG 21 as “convenor emeritus” and bringing evolution proposals to the committee, I’ll continue serving as chair and CEO of the Standard C++ Foundation and all roles related to that, and I’ll keep speaking and writing… including that I intend to keep writing these post-meeting trip reports. But it’s time for others to be able to step up to take on more of the committee’s organizational and administrative work, and I was glad to see we had three qualified and willing candidates!
ISO has selected Guy Davidson as the next WG 21 convenor, effective January 1. Thank you Guy for making yourself available, and thank you too to John Spicer and Jeff Garland who also volunteered themselves as convenor candidates! Prior to this new role, Guy was co-chairing the SG14 Gaming/Low-Latency subgroup. He also had other prominent C++ community leadership roles outside of WG 21, ranging from founding the #include diversity and inclusion group to being an organizer and/or track chair at multiple C++ conferences including ACCU and CppCon which I understand he will continue to do.
Realizing that being convenor of our large WG is quite a big job, Guy wisely immediately appointed two vice-convenors…
Nina Ranns is now a vice-convenor. Thank you, Nina! Nina has been serving as WG 21 secretary for many years and is chair of our SG22 C/C++ liaison subgroup. She also handles many C++ community responsibilities outside of WG 21, including being vice-chair of the Standard C++ Foundation and a compiler writer working on implementing the C++26 contracts feature in GCC.
Jeff Garland is also now a vice-convenor. Thank you, Jeff! Jeff has been serving as an assistant chair of our LWG Library Wording subgroup since 2019. In the wider C++ community, he is a longtime Boost library developer (date-time), coauthor of the original std::chrono proposal, one of the original founders of the C++Now (then BoostCon) conference. More recently, he became executive director of the Boost Foundation and was a cofounder (and now a lead) of the new Beman project dedicated to providing future standard library implementations today.
Now that Nina is moving from secretary to vice-convenor, we also need a new WG 21 secretary: Braden Ganetsky has graciously volunteered to take on that role. Thank you, Braden! Already at this meeting, Braden once again took notes for all but one session of the week-long EWG Language Evolution subgroup sessions, which is a huge job that earned him a big round of applause on Saturday. Outside WG 21, he currently works on low latency trading systems (and designs and builds cool 3D puzzles).
Thank you very much again to Guy, Nina, Jeff, Braden, and everyone who volunteers their time and skills to help organize and run the ISO C++ committee!
During the meeting, John Spicer (who has long chaired our whole-committee plenary sessions, and leads Edison Design Group, EDG) also hosted a lovely reception for the whole committee. The reception was to celebrate the occasion of the new leadership changes, but also that John too is stepping back from chairing the U.S. C++ committee and running our WG 21 plenary sessions. John is one of the C++ committee’s longest-serving members since the early 1990s, and his company EDG has been a leading producer of compilers for C++ and other languages. John recently announced that, after a successful and storied career, it’s time for EDG to wind down, and EDG plans to open-source its world-class C++ compiler front-end within the next year.
And so I want to especially call out and congratulate John Spicer and everyone at EDG (including EDG’s retired founder Steve Adamczyk, other key long-time members such as William (Mike) Miller and Daveed Vandevoode, and everyone else who’s been part of the EDG family over the years) as role models — not only for their high quality compilers but for being high integrity people. Perhaps the best example of their integrity was what happened with the C++98 “export template” feature over two decades ago: In the mid-1990s, John was the most vocal person pointing out technical problems with the feature; the committee decided it did not agree and standardized the feature anyway over his and EDG’s sustained objections; and then instead of sitting back and saying “we told you so,” EDG ended up being the only company in the world who ever implemented the feature! To add a sense of proportion: It took the same team longer to implement just the C++98 export template feature than to implement a compiler front-end for the entire Java language. But John and EDG went and did it, to support the committee’s consensus decision… only to have the committee remove export template again a few years later, because John and EDG had been right about the feature’s problems. That’s a model of solid professional behavior. Thank you again, very much, to John, Steve, Mike, Daveed, and everyone at EDG, past and present.
What’s next
Our next meeting will be in March in Croydon, London, UK hosted by** Phil Nash**. There is ongoing lively debate about whether this is the “Croydon meeting” or the “London meeting,” and whether Croydon is or is not part of London (despite that it’s inside the M25 loop). I think there’s a good chance this will continue to be the biggest controversy; if so, we’re in excellent shape.
Thank you again to the about 200 experts who attended on-site and on-line at this week’s meeting, and the many hundreds more who participate in standardization through their national bodies! And thank you again to everyone reading this for your interest and support for C++ and its standardization.