C++ just made history — and not in a good way. On October 23, the C++26 Draft International Standard failed its ISO ballot for the first time in the language’s 28-year standardization record. The vote was 13 in favor, 9 against, and 12 abstentions — missing ISO’s two-thirds-majority threshold. All nine “no” votes cited the same thing: Contracts. The committee that decides what comes next meets in Búzios, Brazil on November 16.
What Contracts Actually Does
Contracts — formally proposal P2900 — is C++’s long-awaited design-by-contract mechanism. It adds three constructs to function declarations: pre() for preconditions (the caller’s responsibility), post() for postconditions (the implementer’s responsibility), and contract_assert() for mid-function checks. A minimal example:
double sqrt(double x)
pre(x >= 0.0)
post(r: r >= 0.0); // ‘r’ names the return valueThe feature has four enforcement modes — ignore, observe, enforce, and quick_enforce — letting teams configure runtime behavior per build type. In ignore mode, annotations exist but are not evaluated: zero overhead, documentation-grade correctness hints. In enforce mode, violations call a handler and terminate. The idea has been in development inside WG21 for over a decade.
Why It Got Blocked
Bjarne Stroustrup — the person who invented C++ — called the current design “fundamentally flawed,” listing specific grievances: “adding new insecurities, leaving key facilities implementation defined, restricting violation handling, adding overheads, incomplete.” His core argument is that Contracts in its current form violates C++’s zero-overhead principle: in production builds where enforce mode is stripped, there are no safety guarantees, only the fiction of them.
The performance data backs him up, at least partially. HFT University tested GCC 16’s experimental Contracts support and found that an enforced contract generates more machine code than an equivalent if check in some cases. For a language whose entire value proposition in safety-critical and embedded systems is predictable overhead, that is a real problem — not a theoretical one.
Supporters of Contracts are equally firm. Andreas Fertig, a WG21 member who backed the proposal, pointed out that the committee reviewed and approved P2900 in multiple votes over years of work. A late-stage rejection at the ISO ballot — after the draft was already complete — “damages trust in a process that depends on collaboration and compromise.” Timur Doumler submitted a formal paper (P4433R0) arguing explicitly against removal. Neither side is wrong about their facts, which is exactly why nine countries voted no.
What Still Ships in C++26
Here is the thing the “C++ is in crisis” takes are missing: Contracts is one feature. The rest of C++26 is untouched and it is a landmark release by any measure.
Static reflection (P2996) is the headliner. Compile-time code introspection with zero runtime overhead — the binary sees none of it. Reflection enables generic serialization, automatic bindings, and annotation-driven code generation without external tools. The patterns it unlocks will define C++ library design for the next decade.
std::execution (P2300) standardizes async programming around senders, receivers, and schedulers. Lazy evaluation, predictable overhead, and a portable interface for concurrent systems — previously requiring third-party libraries like Asio or Intel TBB to get right.
std::simd (P1928) gives C++ standard SIMD support: explicit, portable, and predictable vectorization. The std::where mechanism enables branch-free conditional execution, replacing a zoo of compiler-specific intrinsics.
Library hardening — uninitialized reads now carry defined erroneous behavior rather than undefined behavior — has real production impact. Google deployed a comparable hardened standard library across its fleet and saw a 30% reduction in segfault rate. That is Contracts-independent and ships regardless of what happens in Brazil.
The Three Paths Out of Brazil
WG21 meets November 16–21 and has three options. First: remove Contracts from the draft, ship a revised C++26, and submit for another DIS ballot targeting March 2027. The formal standard would carry the label ISO/IEC 14882:2026 or 14882:2027 depending on timing. Second: move Contracts to a separate Technical Specification, letting the committee refine the design without blocking the main standard. Third: skip C++26 entirely and let the next standard arrive as C++29 — breaking the three-year cycle the community has relied on since C++11.
The most likely outcome is option one or two. Enough members want to preserve the release schedule that removal or TS separation has stronger consensus than delay. The C++26 feature set is too strong to abandon over one disputed proposal.
What to Do Right Now
Do not freeze your C++26 migration planning over this. Reflection, std::execution, and std::simd are unaffected by the ballot outcome. GCC 16, released in April 2026, supports most C++26 features today — Contracts experimentally with -fcontracts, everything else more stably with -std=c++26. Clang’s mainline does not yet support Contracts, which tells you something about where compiler consensus actually stands.
If your codebase depends on design-by-contract for safety guarantees, the interim options are GSL’s Expects()/Ensures() macros, custom assertion frameworks, or MISRA/AUTOSAR guidelines depending on your domain. These are not ideal, but they ship today and have compiler support across the board.
Watch WG21’s communiéqué from Búzios, expected by November 21. That is when the path for C++26 becomes clear. The standard is not in crisis — one feature is in dispute, and the ISO process is doing exactly what it exists to do.
