Image: The official C++ logo (isocpp.org), public domain. The language's next standard was just rejected in its ISO ballot — the first time that has ever happened to a C++ draft.
📌 Key Highlights
- The C++26 draft failed its ISO DIS ballot, which closed on 23 October 2026 — a first for any C++ standard, and possibly for any programming-language standard from ISO's SC22 subcommittee.
- It failed both tests at once: 12 of 20 voting members in favour (needed 14) and 9 of 22 votes against (the limit is 5). Either failure alone would have sunk it.
- Accounts of the vote name nine countries voting No — Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain and Sweden — and point to one feature: contracts.
- Contracts let functions state preconditions and postconditions, but the draft leaves it to each compiler to decide whether a check runs at all. That is the heart of the argument.
- Reflection, std::execution and standard-library hardening are stuck in the same unapproved draft. The next C++ committee meeting, 16–21 November in Búzios, decides the way forward.
What happened?
Since C++11, the language has shipped a new standard every three years: C++14, C++17, C++20, C++23. The ballot that approves each draft — the Draft International Standard (DIS) ballot by ISO's national bodies — had always been a formality. Language release cycles can change abruptly, as our Node.js 27 alpha explainer showed for JavaScript's runtime. On 23 October 2026, after a twelve-week voting period, C++'s run ended.
Robert Seacord, convenor of the C committee, announced the result tersely on LinkedIn the next day: "Balloting has completed for C++26. Unfortunately it was Disapproved." Committee member Mateusz Pusz, who sits on Poland's national body, wrote that as far as he knows it is the first C++ draft ever to fail a DIS ballot. Seacord added that he does not think any language standard from SC22 has ever failed this ballot, and Daveed Vandevoorde of the C++ committee's direction group wrote that no earlier C++ draft had received even a single vote against.
A DIS ballot has two conditions, and C++26 met neither:
| Condition | Required | Result |
|---|---|---|
| Votes in favour from voting (P) members | At least two-thirds | 12 of 20 — 60% (14 needed) |
| Votes against, from all countries that voted | At most 25% | 9 of 22 — 41% (5 allowed) |
Of the 28 P-member countries, 12 voted to approve, 8 voted to disapprove and 8 abstained. One additional vote against came from an observer (O) member, bringing the total against to nine. Either shortfall alone would have been enough to reject the draft.
Accounts of the vote name the nine countries that voted No as Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain and Sweden, all with technical comments. France and Ireland abstained but also sent comments; Poland and the United States abstained. India was not among the nine countries reported as voting No. The full comments are not public yet: ISO rules require a complete report within 12 weeks of the vote, so they are due by mid-January 2027 at the latest.
C++26 failed ISO ballot explained: what are contracts?
Contracts are the feature at the centre of the dispute. They let a programmer write, in a function's signature, what must be true before it runs and what must be true after it returns. A precondition is written with pre, a postcondition with post, and a check inside the body with contract_assert:
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;
}
Almost everyone likes the idea. A contract is documentation the compiler understands — a requirement that cannot silently go stale the way a comment can. As Pusz puts it, concepts already do this for the types a function accepts at compile time; contracts would do the same for values at run time.
The problem is in the details. The draft defines four evaluation semantics — ignore, observe, enforce and quick-enforce — and leaves the choice to the implementation. In GCC 16, which already ships contracts as experimental support, you pick one with a compiler flag. So the same check can do nothing in one build and abort the program in another. One independent test compiled a single postcondition four ways in GCC 16.1: two of the four builds exited successfully on a bug the check was written to catch, and one of those never said a word.
That is the core of the argument: is a contract a check the build may drop at no cost, or a guarantee the program can rely on? There is also debate about what happens when the check itself misbehaves, and whether there was enough production experience before standardising the design. Contracts were already removed from the C++20 draft at the last minute, in Cologne in 2019, for similar reasons.
Why nine countries voted No
The formal comments are not public, so nobody can yet say with certainty what each No vote was about. But Pusz says he is convinced all nine were about contracts, and the record points that way: both objections raised at the plenary that sent C++26 to ballot were about contracts, several countries had already asked to remove them at an earlier stage, and one paper — P4238R1, from the C++ Alliance — explicitly asked national bodies to vote No over the contracts design and how it had been approved.
The split reaches the top of the language. Bjarne Stroustrup, who created C++, voted against the draft as a member of the US delegation, and argues with four co-authors that the contracts design is too complicated, insufficiently proven in practical use, and does not provide the guarantees they want. He has called the design, as a claimed minimum viable product, "not minimal, not viable." Herb Sutter, chair of the C++ committee, supports the design as it stands.
The supporters' case is that the feature was not rushed: contracts have been developed in their current form since 2019, and the WG21 plenary adopted contract assertions by 100 votes to 14, then approved the draft for ballot by 114 to 12. Sixteen contract supporters signed a paper, P4433R0, "Do not remove Contracts from C++26", arguing that removing them would itself be a major change — it would force a redesign of standard-library hardening, which partly relies on contracts. Stroustrup's own safety feature, Profiles, was removed from C++26 and may return for C++29.
What's stuck with C++26
The rejection does not only affect contracts. Other long-awaited C++26 features are stuck in the same unapproved draft:
- Compile-time reflection — programs inspecting their own types and functions at compile time, one of the most anticipated features in the language's history.
- std::execution — a new standard model for asynchronous and parallel programming.
- Standard-library hardening — built-in safety checks in the standard library, which partly relies on contracts.
- Annotations and a range of smaller library and language improvements.
Image: Bjarne Stroustrup, creator of C++, at Technex 2014. Wikimedia Commons / Dev_hritwik, CC BY-SA 4.0. Stroustrup voted against the draft as a member of the US delegation.
For now, the current standard remains C++23 — which was itself published so late that it is officially ISO/IEC 14882:2024. Standards work moves at its own pace even when tooling races ahead: our GitHub CodeQL 2.27.3 explainer covers how analysers already support newer language versions, including C23 integers, while the standards process lags behind. Compilers are unaffected in the short term: GCC 16 accepts -std=c++26 and implements contracts experimentally, and Clang offers -std=c++2c, though its contracts implementation has not been merged yet. Anyone already using C++26 features does not have to undo anything, but code that uses pre, post or contract_assert with GCC 16 depends on exactly the part that is in dispute.
What happens next: four options and the Búzios meeting
ISO rules give four courses of action after a failed DIS ballot: send a revised draft for a new ballot; send a revised draft back to the committee for comments; publish the draft as a Technical Specification instead of a standard; or cancel the project. Under the ISO directives, the decision rests with the SC22 chair, in consultation with the SC22 secretary, the WG21 convenor and the ISO chief executive's office.
The positions are divided. One camp, including J. Daniel García, one of the authors of P4238R1, says the short-term solution is simple: remove the one problematic feature and the rest of the standard can very likely be approved; Vandevoorde is expected to recommend the same. The other camp, the sixteen signatories of P4433R0, wants a second vote without changing contracts, arguing that removing them would not be quick either.
All of it comes to a head at the next WG21 meeting in Búzios, Brazil, from 16 to 21 November 2026 — ten days away. Committee member Andreas Fertig, who represents Germany's vote, says the next steps are "more than uncertain". If contracts are removed and the draft is re-balloted, the standard could still be published in the second half of 2027 at the earliest — and if it is published in 2027, Vandevoorde thinks "C++27 would make sense" as a name. The project was registered on 2 January 2025 and must reach the approval stage by the end of 2027, unless an extension of up to twelve months is obtained, or it faces automatic cancellation. The three-year cycle that has held since C++11 will miss its next milestone either way.
What it means for Indian developers
C++ runs a large share of India's systems software — embedded and automotive code, telecom equipment, high-frequency trading systems, game engines, and the tooling behind space and defence programmes. For Indian developers, the practical consequences are straightforward — and the tooling around the language keeps moving regardless, as our RustRover 2026.3 explainer shows for the IDE side of modern C++ and Rust work.
First, nothing changes today: C++23 remains the current standard, and code written against it is unaffected. Second, do not build production guarantees on contracts yet — the feature's semantics are exactly what is being fought over, and a check enforced in one build may be compiled away in another. Third, teams planning upgrades should watch Búzios: a contracts-free C++26 (or C++27) in late 2027 is the most likely outcome, but a Technical Specification for contracts, or a longer deadlock, are both live possibilities. And for students, "why was C++26 rejected?" is now a genuine interview question — the honest answer is one word: contracts.
Should you care?
FAQs
Why was C++26 rejected?
C++26 failed its ISO DIS ballot on 23 October 2026 because of the contracts feature. It needed at least two-thirds of voting members in favour and no more than 25% of votes against; it got 60% in favour and 41% against. Committee members and multiple accounts of the vote say the nine No votes were about contracts, though the formal comments are not public until mid-January 2027.
What are C++ contracts?
Contracts let you state conditions on a function: pre for what must hold before it runs, post for what must hold when it returns, and contract_assert for checks inside the body. The dispute is that the draft defines four evaluation semantics — ignore, observe, enforce and quick-enforce — and leaves each compiler to choose, so the same check can do nothing in one build and abort the program in another.
When will C++26 be released now?
There is no date. The WG21 committee meets in Búzios, Brazil, on 16–21 November 2026 to choose between removing contracts and re-balloting, voting again unchanged, publishing as a Technical Specification, or cancelling the project. If contracts are removed and the draft is re-balloted, publication in the second half of 2027 is the earliest realistic outcome — and it may be renamed C++27.
Will C++26 be cancelled?
Cancellation is one of the four options, but it is the least likely: it would require a WG21 majority, and it would mean reverting to C++23 and moving every C++26 feature to C++29 one paper at a time. The project must reach the approval stage by the end of 2027 or face automatic cancellation unless an extension is granted. Most observers expect contracts to be removed or parked in a Technical Specification instead.
Can I still use C++26 features in GCC 16?
Yes. GCC 16 accepts -std=c++26 and implements contracts as experimental support, and Clang offers -std=c++2c. The ballot changes nothing about what compilers already ship. But code using pre, post or contract_assert depends on the disputed part of the draft, so treat it as experimental, not as a guarantee.
Takeaway: For the first time ever, the countries that approve C++ said no — and they said it over a single feature. The language is not broken, C++23 still works, and the most likely outcome is a contracts-free standard in 2027. But the vote exposed a real split about what a safety check is allowed to promise, and that argument will shape C++ for years.
Read Mateusz Pusz's full write-up of the ballot result for the committee's own account — and watch for the outcome of the Búzios meeting on 16–21 November, when the next standard's fate is decided.
Sources
- Mateusz Pusz, "The result of the C++26 DIS ballot", Train IT — committee member's account of the vote, the numbers and the four options (25 October 2026).
- Andreas Fertig, "C++26 Disapproved" (archived copy) — WG21 committee member on the first failed DIS ballot in C++ history and what happens next (4 November 2026).
- Antonio Cortes, "C++26 fails its ISO ballot, and contracts are the reason" — vote breakdown, the nine No votes, and the Búzios options.
- P4433R0, "Do not remove Contracts from C++26", WG21 — the sixteen signatories' case for a second vote without changes (23 October 2026).
- P4238R1, "Returning C++26 for the Evaluation It Skipped", WG21 — the C++ Alliance paper that asked national bodies to vote No (1 September 2026).
- Reticle, "C++26 failed its ballot over contracts. We compiled one: same code, four outcomes" — GCC 16.1 test showing two of four builds missing a bug the check was meant to catch (26 October 2026).
- Ekansh Jain, "C++26 Got Rejected. Now the Three-Year Cycle Is at Risk.", Medium — the three-year cycle, the 2027 deadline and the Stroustrup opposition.
Comments
Post a Comment