What happened to the C++26 ballot?
The C++26 draft has failed its Draft International Standard ballot, the decisive vote before an ISO standard is published. National bodies had twelve weeks to examine the document. The ballot closed on 23 October 2026, and the result was disapproval.
Robert Seacord, convenor of the C committee (WG14), announced the outcome on LinkedIn the next day. "Balloting has completed for C++26. Unfortunately it was Disapproved," he wrote. The message was short, but the consequence is large: the next C++ standard is now stuck.
Two separate thresholds govern a DIS. The draft needed a two-thirds majority of participating-member votes in favour. It also had to keep negative votes at or below a quarter of all votes cast. It missed both conditions.
Twelve of the 20 participating members voted yes, short of the 14 required. Nine of the 22 votes cast were negative, well above the five allowed. Either count alone would have sunk the draft, according to Mateusz Pusz, a Polish committee member who published the tally.
Eight participating members abstained. The nine negative votes came from eight participating members and from Iran, an observing member. Denmark, Finland, Italy, Japan, Luxembourg, Romania, Spain and Sweden joined Iran in voting no, and all nine sent technical comments.
France and Ireland abstained but also sent comments. Poland and the United States also abstained. Pusz, who sits on the Polish national body, said he would not disclose how its internal ballot divided.
This is the first failure of its kind for the main C++ standard. The C++ Alliance notes that every approval ballot from C++11's FDIS through C++20's DIS passed without a negative vote. The C++23 DIS drew only editorial comments.
The nearest precedent is C++/CLI, a separate specification. Its DIS failed in 2006, with 11 of 20 votes in favour and 9 of 26 against, and the project was halted. Andreas Fertig, a German committee member, could find no other failed DIS in the ISO system.
- •Yes votes: 12 of 20 participating members, or 60%, against the 14 needed for two-thirds.
- •No votes: 9 of 22 cast, or 41%, against a ceiling of 5.
- •Abstentions: eight participating members, including France, Ireland, Poland and the United States.
Why did national bodies reject C++26?
The dispute is about contracts. The feature lets a function state what must be true when it is called and when it returns. A precondition is written with pre, a postcondition with post, and a mid-body check with contract_assert. The syntax is compact, and the goal is old: make assumptions machine-checkable instead of leaving them in comments.
The argument is not about whether checks help. It is about what a contract promises. The draft defines four evaluation semantics: ignore, observe, enforce and quick-enforce. The implementation chooses between them, and cppreference says the choice can differ between evaluations of the same assertion.
Supporters see that flexibility as the reason the feature could be adopted at all. Critics see a check that a build may drop, which makes it advice rather than a guarantee. That split has followed the feature for years.
Contracts were pulled from C++20 in 2019 through paper P1823R0. Its authors said the feature was not ready and that keeping it would put the whole of C++20 at risk. A redesign followed, and WG21 adopted contract assertions into C++26 by 100 votes to 14.
The committee then approved the complete draft for the DIS ballot by 114 votes to 12. Those figures come from P4433R0, a paper signed by 16 supporters of contracts. They show that internal majorities were large, but they do not bind national bodies.
Opposition did not fade. In August 2026, Bjarne Stroustrup, J. Daniel García, Vinnie Falco, John Spicer and Ville Voutilainen published P4334R0, which describes fundamental flaws in the P2900 design. The paper calls the feature an "existential threat to C++". It puts the cost at roughly 56 pages of the draft, for an incomplete version.
Weeks later, P4238R1 from the C++ Alliance asked national bodies to vote no. It argued that contracts had advanced through procedural moves that left sustained objections unresolved. It also estimated that returning the draft would cost one ballot cycle, or months rather than years.
The critics make a technical case as well as a procedural one. P4334R0 argues that contracts focus on debug support rather than durable guarantees. The paper says safety rules often need to cover a whole translation unit, not one call. It also points to a draft ETSI specification that treats C++ as offering no memory-safety guarantees. It says runtime checks do not close that gap.
That argument lands hardest with embedded and safety-critical teams, who need properties they can defend to an auditor. A compiler flag that removes checks in production does not give them that. Supporters answer that contracts remain useful documentation, and that the objections were already heard and decided inside WG21.
P4433R0 rejects that framing. It says every concern was heard repeatedly, and that sustained opposition is not a veto. Removing contracts, it argues, would force a redesign of library hardening.
The comments themselves are not public yet. ISO rules require a full report within twelve weeks. The wording from the eleven countries that commented should appear by mid-January 2027. Until then, the claim that all nine negative votes concern contracts rests on the record before the ballot, not on the comments.
Which C++26 features are now stuck?
Contracts are not the only thing in the failed draft. C++26 also contains compile-time reflection (P2996), the std::execution model for asynchronous code (P2300), and standard library hardening (P3471). All of them sit in the same document, so all of them are now unapproved.
Reflection lets a program inspect its own types and generate code at compile time. std::execution, built on senders and receivers, is the committee's answer to structured asynchrony. Hardening adds checked bounds and other defences to standard containers and algorithms. Each has been presented as a headline feature of the release.
Bundling them is normal ISO practice, and it is also the weakness exposed here. A single contested feature can hold back work that nobody objected to. Pusz, who uses contracts in his own library and teaches them, still argues that the rest of C++26 should not wait.
For compiler vendors, the practical situation is unchanged for now. GCC 16 already accepts -std=c++26 and implements contracts as part of its C++26 support. Reflection is available behind -freflection. Clang accepts -std=c++2c, but its status page lists the P2900 contracts paper as not implemented.
Toolchains ship the working draft, not the approved standard. That distinction matters more than usual when the draft has just been rejected. Vendors can keep every feature behind the flag, change it, or drop it. Whether they do is up to each of them.
The delay also reaches library authors. Standard library hardening is tied to the contracts design. Removing contracts would force the committee to rework the hardening specification, not just delete a chapter. P4433R0 makes that point when it argues that removal is not a quick edit.
Users of the affected features are therefore in an unusual position. Reflection and std::execution may be ready in practice, but their fate is tied to a debate they have nothing to do with. That is the cost of packaging a whole edition as a single ballot question.
What will WG21 do in Búzios on November 16?
WG21 meets in Búzios, Brazil, from 16 to 21 November. It is the first full committee meeting since the result. One question dominates the agenda: remove contracts, or seek another vote without changing them.
ISO gives a failed DIS four routes. The committee can circulate a revised draft for a new eight-week DIS ballot. Alternatives include a committee draft for comments, a technical specification, or cancelling the project.
The SC22 chair chooses among the first three, in cooperation with the secretariat and the WG21 convenor. Cancellation is the only option that SC22 as a whole must decide. No route has an official date attached.
P4433R0 asks WG21 to seek another ballot with contracts intact. It also asks the committee to reject removal comments with no new technical information. The paper wants that position confirmed by poll in Búzios. Its authors argue that a second ballot is the way to protect work that already cleared multiple votes.
Others favour removal. J. Daniel García, one of the authors of P4238R1, argued for the simpler route. Removing "one problematic feature" would very likely let the rest of the standard be approved, he wrote. Daveed Vandevoorde, a member of the direction group, will recommend removing contracts, according to Pusz. He would adjust the plan for library hardening at the same time.
The two camps also disagree about cost. P4238R1 estimates a delay of months, not years. P4433R0 calls the idea that removal is quick "not realistic". Deleting the feature and redesigning hardening would be a major change in its own right.
One detail from Pusz's account matters for how much weight the vote should carry. Poland almost had no position at all, because its national committee was short of a quorum days before the ballot closed. Several listed members had changed jobs, and some contact addresses no longer worked.
He reached enough members in time, but the episode shows how thin national-body participation can be. A country's vote, or its silence, may depend on a handful of volunteers. That is a weakness in the process on both sides of the contracts argument.
Even the name is unsettled. Vandevoorde doubts the draft can be voted out in 2026. He has said C++27 would make sense if publication slips to 2027. C++23 was published as ISO/IEC 14882:2024 for administrative reasons, and the community still calls it C++23.
What does the failed ballot mean for your code today?
For most teams, nothing breaks this week. The published standard is still C++23, formally ISO/IEC 14882:2024. The failed ballot does not withdraw features that compilers already implement, and it does not change code that builds today.
That does not make current C++26 code stable. A draft can change before publication, and a feature under dispute is the least safe bet in it. If your code uses pre, post or contract_assert with GCC 16, you depend on an experimental implementation. That implementation covers exactly the part national bodies rejected.
A small experiment shows why the semantics debate matters. Reticle compiled one function with a postcondition in GCC 16.1, then changed only the contract evaluation flag. With ignore, the program ran to completion and exited 0 despite a double charge. With observe, it printed a violation but still exited 0.
With enforce and quick-enforce, the same program aborted with exit code 134. None of those outcomes is a compiler bug. They follow from a design that lets the implementation choose what a contract does.
For a test build, observe may be enough. For a safety case or a CI gate, it is not. A green exit code can hide the failure the contract was written to catch. That is the practical version of the argument that has now reached ISO.
Teams that want to experiment can check the feature-test macro. GCC 16 defines __cpp_contracts as 202502L or later, according to its status page. If a compiler does not define the macro, it does not claim support, whatever the command-line flag accepts.
It is also worth building the same target twice, once with checks set to observe and once with them set to enforce. A test suite that only passes under observe is not checking what its authors think it is checking.
Teams should treat C++26 support as preview. Pin compiler versions, read vendor status pages, and avoid assuming that a contract behaves the same way across compilers and build flags. The library hardening that C++26 promises is also only partially implemented in current GCC releases, according to cppreference's feature table.
Will C++26 still ship, and when?
One route out of a failed DIS is a revised draft and a second ballot. If WG21 removes contracts in Búzios, that ballot would last eight weeks, and publication in 2027 is plausible. No date has been set.
A second possibility is another ballot with contracts unchanged. That would test whether national bodies will reverse a vote they have just cast with technical comments. It would also consume committee time and leave the rest of the draft exposed to the same dispute.
The third path is more drastic. WG21 could abandon this edition and fold its completed work into C++29, or ISO could cancel the project. Either would delay reflection, std::execution and hardening by years. P4433R0 warns that contracts would lose the foundation its planned extensions depend on.
Watch three things. First, the polls in Búzios, which will show whether the committee can agree on a recommendation. Second, the comment report due by mid-January 2027, which will confirm what the nine objectors actually asked for. Third, the SC22 chair's choice of procedure, because that sets the timetable.
The deeper issue is governance. A DIS ballot is the one point where national bodies can reject work the committee has already approved. This time they used it, and the result exposes how much of C++26 depends on a single contested feature.
Whether the committee treats that as a signal or an obstacle will shape the next standard more than the vote itself. For developers, the safe assumption is that the draft they can compile today is still a draft. The features most likely to change are the ones now under review.