The Shape of Code

The vote to replace the ISO 2023 C++ Standard with an updated version has failed. Of the 28 P-member countries of SC22, 12 voted Approval, 8 voted Disapproval, and 8 Abstention. At least 66.66% of Approval votes are required (received 60%) and less than or equal 25% of Disapproval votes (received 41%), with Abstention votes not counting towards the total, and Disapproval votes by O-member countries counting towards Disapproval (there was one).

This post discusses the available courses of action over the next 12 months and then looks at factors influencing the continual evolution of the C++ Standard.

Some background for new readers. SC22/WG21, the ISO C++ committee, has been publishing new revisions of the C++ Standard on a 3-year schedule (i.e., 2011, 2014, 2017, 2020, and 2023), and until this setback was going to start work on 2029 at the next committee meeting. WG21 meet three times a year, with the week-long meetings attracting around 200+ people, who have a selection of 23 active subgroups to participate in. On average, there are 108 papers up for agenda time to discuss, and 147 post-meeting papers (average since 2024). This is industrial scale document processing.

What motivates 200+ people to regularly attend a gruelling week-long session of detailed technical C++ discussions? I have long said that the C++ committee has become a playground for bored consultants looking for a creative outlet. There are also the speakers and consultants who make their living talking about what’s new in C++, and giving training courses on the latest features of the language. The implementors are a tiny, but influential minority, because there are not many implementations. The energy driving WG21 comes from the people who attend. The bored consultants want their pet language feature adopted into the C++ standard, the speakers/consultants need something new to talk about, and the implementors need new features to be paid to implement (hopefully; funding is tough). WG21 is its attendee’s gravy train.

Nobody inside WG21 wants the gravy train to stop, so what happens next?

When a country votes Disapprove, they are required to specify what action the committee needs to take for them to change their vote to Approve. Removing contracts from the draft is what is required to turn the majority of Disapprove votes to Approve (various editorial issues were also requested by various countries). Contracts almost made it into the 2020 Standard, but was withdrawn at the last minute.

The WG21 committee has two options, and their next meeting starts in 2 weeks, 16th November, in Brazil:

• agree to remove contracts, and vote to send the revised draft for another DIS (Draft International Standard) ballot at their March 2027 meeting (or June if the editorial work is not complete by March). The ISO directives specify that a second DIS ballot lasts 12 weeks, so the current draft minus contracts would be published around the third quarter of 2027, at the earliest. These directives also specify that a committee can only make changes that address Disapprove comments and cannot do any work revising a draft that is out for ballot.

  The bored consultants have already spent almost a year sitting on their hands, while the current draft standard went through the (failed) approval process. Will they be willing to spend another year without their fix of C++ bike shedding?

• skip to C++ 2029, i.e., not submit a contractless draft for voting, so C++ 2026/7 does not happen.

  This immediately restarts the gravy train. If the supporters of contracts believe that the existing wording can be tweaked to make it broadly acceptable, they might not be willing to see it removed from the draft.

How contentious is the current specification of contracts? The 8 Abstentions is rather telling. Eight countries with people actively involved in WG21 work failed to reach consensus, including the US (the convention is for countries without active participation to be polite and vote Approve). Stroustrup, as a member of the US delegation, voted against the proposal, and has said (53 minute mark) “…it’s claimed to be a minimal viable product. It’s not minimal, it’s not viable.”

Contentious issues sometimes take many meetings to resolve. An extreme case is the 13-years before Fortran-77 became Fortran-90, with meetings described as “… two major vendors against the majority of X3J3 [ANSI Fortran committee] …”

One of the jobs of the chair of WG21, before forward a document for DIS balloting, is to be confident that consensus has been achieved. There was a change of committee chair at the start of this year. Even so, he is going to be in the hot seat at the next SC22 meeting.

What of the longer term future of work on the C++ Standard?

For some time I have been saying that WG21 is past its sell by date. The supporters of 3/4 industrial C++ compilers could meet together to agree new language features and their semantics, just like ECMAScript (aka JavaScript) and Java.

However, work on standards is controlled by those who do the work. If enough people continue to turn up at WG21 meetings and write papers, then the C++ Standard will continue to evolve. Cobol 2014 looked like it would be the final standard for the language, but as retirees like to say “I just had my eyes closed”, and we now have Cobol 2023 (the COBOL front end for gcc, which now supports COBOL 85).

The availability of LLMs creates two threats to established WG21 work practices, and a potential benefit.

• The committee was straining under the volume of submitted papers, proposing changes, before LLMs arrived. Now that the effort needed to write and format a proposal has been significantly reduced, the number of papers submitted is likely to increase. While voting was underway, there were 116 papers in the May 2026 pre-Brno mailing, of which five acknowledge LLM assistance, thirty are very likely have had LLM assistance (according to Devin), and three possible uses of LLM,
• the wording of the requirements in the C++ Standard has always been somewhat lax and open to interpretation (speaking as someone coming from a C Standards background, where there is a lot less ambiguity). Previously finding inconsistencies and ambiguities in the Standards’ document required a broad and deep understanding of that document. LLMs have removed the need for a broad/deep understanding of the language. If somebody were to decide to reduce the inconsistencies/ambiguities in the C++ Standard, they could use LLMs to submit a stream of issue requests, whose impact would be to overwhelm the current process, which currently has around 100 new issues added annually to the language issues list and around 250 added annually to the library issues list (averaged over the last few years),
• coding agents provide a mechanism for removing a ball-and-chain that restrains all programming language committees (the compatible with C ball-and-chain was dropped in 2018). Compatibility with existing code, which conforms to the existing standard, is an oft cited reason for not changing existing behavior specified by the standard. Coding agents could significantly reduce the cost of updating existing code to handle changes to the semantics of C++. I’ll skip over the issue of how coding agents are trained on new language/library semantics, given that the only examples are contained in the proposal paper(s).

Given the expanding creative abilities of coding agents, the number of bored consultants is likely to grow. There will be a C++ 2032/3, whether the world wants/needs it or not.