C++26 rejected by ISO: a first in the language’s history

Forty-something years of C++ standards and not a single one had ever been voted down. Not C++98, not the messy C++11 revolution, not C++20 with its half-baked modules. Then on October 23 the national bodies voted on the C++26 draft, and C++26 got rejected by ISO. Robert Seacord, who chairs the C committee, called it “a sad day for the C++ community” the next morning.

I’m not even a C++ person and I found this fascinating, because it’s less a story about syntax than about how a giant committee can spend twenty years on an idea and still trip at the finish line.

C++26 rejected by ISO: the numbers

To pass, a draft needs two-thirds of participating members voting yes, and no more than a quarter voting no. C++26 managed 12 yes votes out of 20, which is 60 percent, when 14 were needed. On the other side, 9 of 22 ballots were negative, a hefty 41 percent. Failed on both counts, no wiggle room.

The no camp, according to committee member Mateusz Pusz who saw the official tally, was Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain and Sweden. France and Ireland abstained but sent technical comments. Poland and the United States abstained and said nothing. Daveed Vandevoorde of the C++ direction group pointed out that no previous draft had ever received even one negative vote. Nine is a statement.

Contracts, the feature everyone wanted and nobody agreed on

The sticking point is contracts. The idea is simple and old: you write right in a function’s declaration what it demands from callers (a precondition, say a positive number for your square root) and what it promises back (a postcondition). Bertrand Meyer popularized it in the 80s with Eiffel, Ada and D have had it for ages. The C++ committee has been chewing on it since 2004. A version was slated for C++20 and yanked in 2019. The current attempt even sailed through a technical subgroup in February 2025, 100 votes to 14.

So what went wrong? Not the concept, the semantics. In the C++26 draft your source code doesn’t decide whether a contract gets checked. The implementation does, via four possible modes: ignore it, check and report without stopping, check and terminate, or terminate on the spot. In plain terms, a compiler flag decides if your carefully written guarantee is enforced, merely logged, or silently thrown away. Pusz framed the question neatly, as Next reported: is a contract assertion a check the build can strip out, or a guarantee the program can rely on?

Opponents, Bjarne Stroustrup among them (yes, the guy who invented the language), see it as institutionalizing the old habit of testing with checks on and shipping with checks off. They’d rather have them always on, which Google priced at about 0.3 percent of overhead. They also grumble that contracts on virtual functions got punted to C++29, so the feature ships incomplete. Supporters say all of that was answered already, and that pulling contracts now means another six-year detour, which is exactly what happened after the C++20 removal. Some of them also accuse the other side of lobbying national delegations directly during the vote. Lovely atmosphere.

What changes for your code

Right now, almost nothing, and that’s the slightly absurd part. Compilers don’t wait for ISO’s rubber stamp. GCC 16, out since April, already supports contracts experimentally behind -std=c++26. Clang doesn’t yet. Your toolchain this morning is the same as yesterday, and the vote doesn’t retroactively unship anything. It’s a bit like Wi-Fi standards, where routers ship “draft” support years before the paperwork lands.

The real action is in Búzios, Brazil, where WG21 meets from November 16 to 21. The committee has to answer every national comment (which, charmingly, we’re not allowed to read) and pick a path: a revised draft and a new eight-week ballot, a fresh committee draft for comments, publication as a mere technical specification, or outright abandonment. Some members want to resubmit the exact same text and dare the no voters to do it again. Others want to rip out contracts so the rest of C++26 (and there’s a lot of good stuff in there) can finally ship. Either way, the calendar is probably sliding into 2027, and the thing may well get renamed C++27, which would be the most honest thing to come out of this process.

If you follow language drama, this feels like a cousin of the CPython JIT removal I wrote about last week: big, ambitious feature, years of effort, then a reality check at the last step. The difference is Python’s core team made that call themselves. C++ got it from Iran and Luxembourg.

Turns out the one thing C++ couldn’t specify was whether its own promises mean anything.