C++26 Hit a Wall. One Feature Is to Blame

C++26’s journey to standardization hit an unprecedented roadblock on October 24, 2026. The draft failed its ISO Draft International Standard (DIS) ballot, marking the first time a C++ standard has ever been disapproved at this critical stage. This all-or-nothing vote required member bodies to approve the complete draft, not individual features.

Results from the ballot were stark: among participating members, only 60% (12 of 20) voted yes, falling short of the required two-thirds majority. Compounding this, 9 of 22 member bodies cast "No" votes, exceeding the 25% cap allowed for disapproval, reaching an alarming 41%. This wasn't a cancellation of C++ or a blanket rejection of every C++26 feature; it was a decisive thumbs-down on the entire package, driven by profound disagreements over a single contentious proposal.

This outcome confirms that national bodies are not mere rubber stamps. The disapproval means the C++26 standard, as drafted, will not proceed. The community now faces the complex task of reassessing and revising the draft, potentially delaying the release significantly.

Contracts, the proposed runtime checks for C++26, became the undisputed deal-breaker. This feature, detailed in P2900, aimed to introduce built-in preconditions, postconditions, and assertions directly into the language, allowing developers to specify expected program states and behaviors.

This wasn't a minor addition; Contracts alone swelled the draft standard by approximately 56 pages. The proposal specified four implementation-defined evaluation modes: ignore, observe, enforce, and quick-enforce. This flexibility, intended to adapt to various deployment scenarios, instead fueled significant opposition.

Critics, including C++ creator Bjarne Stroustrup, viewed Contracts as a large, incomplete design fraught with peril. They argued it introduced unnecessary complexity, new avenues for undefined behavior, and a fundamental design flaw: runtime checks that could be (and likely would be) disabled in production builds. This, they contended, undermined C++'s core principle of zero-overhead and offered a 1980s solution to a problem better addressed by modern static analysis.

Bjarne Stroustrup, the creator of C++, didn’t just dislike Contracts; he helped lead the charge against it. In August, Stroustrup and four co-authors — J. Daniel Garcia, Vinnie Falco, John Spicer, and Ville Voutilainen — published P4334R0, “P2900 Contracts' Fundamental Flaws.” This paper called the proposal an “existential threat to C++” and dismissed its approach as a “1980s approach that ignores ~50 years of progress.”

The core design divide is stark. Critics, including Stroustrup, advocate for coherent static analysis and robust safety guarantees, arguing that runtime-only checks violate C++’s zero-overhead principle by being stripped from production builds. They also contended the proposal introduced new undefined behavior risks and unproven inheritance models.

Supporters, however, view runtime contracts as a practical, immediately useful tool for expressing and checking program assumptions, a necessary feature for modern development. For further reading on the proposal, see P2900: Contracts for C++.

The counterargument to Stroustrup’s zero-overhead concern is equally compelling: a functioning standards process should scrutinize a proposal this deeply, rather than rubber-stamp a committee compromise. The C++26 rejection proves national bodies are paying attention, ensuring that new features meet the highest bar, even if it delays the standard. This isn't just about Contracts; it’s about the integrity of the entire standardization process.

The C++26 ballot’s all-or-nothing nature means Contracts didn’t just fail alone; they took the entire standard with them. Highly anticipated features, like static reflection and std::execution, now languish in limbo. This collateral damage is a bitter pill for a community eager for progress.

This stalemate arrives as C++ faces increasing scrutiny to improve software safety and reliability. Competing languages like Rust and Swift offer memory safety guarantees and robust concurrency models, putting pressure on the C++ Standards Committee to evolve. The industry demands more than just performance; it demands provable correctness.

Now, the committee must chart a difficult course. Options include reviewing national comments and addressing concerns, or, more drastically, removing Contracts entirely to salvage the schedule. A narrower compromise might emerge, but the final path and its timeline remain deeply uncertain. This vote proves one feature can indeed hold everything up.

Why did the C++26 draft fail its ISO ballot?

The draft fell short of the required approval threshold and exceeded the allowed share of negative votes. Disagreement over the Contracts proposal was widely seen as the central cause.

What are Contracts in C++?

Contracts are proposed language features for expressing preconditions, postconditions, and assertions that can be checked at runtime.

Did the vote reject all of C++26's features?

The ballot covered the complete draft standard, so the draft failed as a whole. The objections described in the source focused primarily on Contracts, not every C++26 feature.

What happens to C++26 after the failed vote?

The committee must review national-body comments and decide whether to remove Contracts, revise the proposal, or pursue another route. The release timeline is uncertain.