On 23 October, after a twelve-week voting period, the C++26 draft came back from its Draft International Standard (DIS) ballot marked Disapproved. As far as anyone involved can determine, no C++ standard has ever failed that step before — and, according to Robert Seacord, who convenes the C committee and announced the result on LinkedIn the following day, possibly no language standard in ISO's SC22 subcommittee either.
The numbers
A DIS draft has to clear two thresholds at once: two-thirds of the votes cast must be yes, and no more than a quarter may be no. C++26 missed both. It needed 14 yes votes and received 12; up to five no votes were allowed and there were nine. Either failure alone would have sunk it.
Nine national bodies voted against — Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain and Sweden — each with technical comments. France, Ireland, Poland and the United States abstained. Under ISO rules the comments themselves stay sealed for twelve weeks, so the full record will not be public before mid-January 2027.
Contracts are the objection
The comments are not readable, but the trail is: every position on record before the ballot pointed at the same feature. Contracts let a function declare what must hold on entry and on exit, and assert conditions inside its body.
```cpp double checked_sqrt(double x) pre(x >= 0.0) post(r: r >= 0.0) { const double root = std::sqrt(x); contract_assert(!std::isnan(root)); return root; } ```
Few people object to the idea — compiler-checked documentation that cannot go stale the way a comment does. The fight is over the semantics. The draft defines four evaluation modes, `ignore`, `observe`, `enforce` and `quick-enforce`, and leaves the choice to the implementation, so in GCC 16 the same contract is either a check that vanishes in a release build or a runtime guarantee that terminates the program. The countries that voted no argue that something a build is free to drop is not a contract at all, and that the feature had not seen enough production experience before standardisation. Contracts were pulled from C++20 for related reasons in 2019; a study group then spent roughly four years on the design before the evolution group and, in March 2026, WG21 itself approved it.
That procedural history is the other half of the grievance. WG21 — the C++ committee — sent C++26 to ballot with contracts by more than the required two-thirds. The DIS vote was taken by national bodies whose delegations are not always the people who sat through that debate, and one paper, P4238R1, explicitly asked them to vote no over the contracts design and how it had been approved. Members describe the result as a rupture in the trust that the "we lost the vote, we accept it" norm depends on.
The collateral damage
The rejection does not single out contracts. Everything else in the draft is stranded with them: compile-time reflection, `std::execution` as the standard model for asynchronous code, and the standard library hardening work that partly leans on contracts.
Four exits, none of them quick
ISO rules allow a revised draft to go to a new DIS with a shorter eight-week vote; a return to committee draft for another comment round; publication as a technical specification; or cancelling the project. All four need a majority inside WG21 — the same body that voted for C++26 with contracts — and both camps have years of work invested in their position. Removing contracts to unblock the rest is the fastest route and the one several prominent members now advocate; sixteen contract supporters have signed a paper asking for a re-vote without changes instead. The next meeting runs from 16 to 21 November in Búzios, Brazil, and this is the only item that matters.
The name will resolve itself: publish in 2027 and "C++27" is the obvious label. C++23 was late enough to be formally ISO/IEC 14882:2024.
What it means if you write C++ today
Nothing is retracted. Compilers implement the working draft: GCC 16 accepts `-std=c++26` and ships contracts as experimental, Clang has `-std=c++2c` with its contracts implementation not yet merged. That is still draft code, and if you use `pre`, `post` or `contract_assert`, you are building on precisely the part now in dispute. If contracts are removed to unblock the standard, expect source changes.
The deeper lesson is not about C++ syntax. It is how hard it is to add "check that the argument is positive" to a language with four decades of code, several compilers and users with opposite needs: for some, a check must be removable at zero cost; for others, a check that can be removed is not a guarantee. The committee has been unable to satisfy both, and the national bodies have now said so in the one place where the answer is binding.
