C++26 fails its ISO ballot over Contracts, whose safety checks can be switched off per build
A Polish committee member lists what ISO can do next, from a quick revote to cancelling the project, and the C++ committee meets in Brazil on November 16 to start deciding.

“Balloting has completed for C++26. Unfortunately it was Disapproved.” That is Robert Seacord, in a LinkedIn post that Mateusz Pusz of Train IT quotes in his write-up of the result. Pusz runs a C++ training company in Gdańsk, sits on the Polish national body and on the committee’s LEWG, and writes that “as far as I know, it is the first C++ draft to fail one.”
His evidence for “first” is two statements from other people. Seacord said he doesn’t think any SC22 language standard has failed its ballot before. Daveed Vandevoorde said no earlier C++ draft got even a single vote against.
The vote numbers come from a separate blog post, from the writer behind Here Comes the Moon. Pusz gives no counts and notes ISO policy doesn’t allow sharing how national bodies voted, so treat these as that blog’s tally. It says 12 of 20 voting members approved, which is 60% against the two-thirds the rules require. It says 9 of 22 national bodies voted no, which is 41% against a ceiling of 25%. The draft missed both bars.
Contracts are the feature at the center. They add pre and post conditions to functions and contract_assert checks inside them, replacing the old assert macro with something standardized. The idea is a function that states what it needs and what it promises, in the code itself.
The trouble is in what a violation does. Per Pusz, the draft defines four evaluation semantics: ignore, observe, enforce and quick-enforce, and leaves the choice to implementations. GCC 16 picks one with a compiler flag. The Here Comes the Moon post lists the options as killing the program, calling a handler and then killing it, logging an error, or ignoring the check entirely.
Now picture a program built with enforcement that links a prebuilt library built with ignore. The blog says the linker keeps one copy of the function and asks what happens then, and whether the checks run at all. Its claim is that there is no way for a user to guarantee they always run. It adds that code inside a check is ordinary C++, so a compiler can remove it by reasoning that the code has undefined behavior.
A contract you can opt out of at build time is a suggestion with better formatting.
The fight predates the ballot. WG21 voted Contracts into the draft at Hagenberg on February 15, 2025, by the blog’s count 100 in favor, 14 against and 12 abstaining, and the Contracts paper, P2900R14, carries the design. Bjarne Stroustrup, per the blog, said it “is not minimal. I don’t think it’s viable.” Herb Sutter’s response paper, P4454R0, has a section titled “Fact 1: WG21 has strong consensus for contracts” and another, “Fact 3: The NBs chose to give Bjarne’s view more weight.”
So a committee majority and a set of national bodies are each sure the other missed something. After a failed ballot, Pusz writes, the directives allow four courses: a revised enquiry draft with an eight-week vote instead of twelve, a revised committee draft for comments, a draft technical specification, or cancelling the project. The SC22 chair picks one of the first three; cancelling takes an SC22 decision.
Standards bodies tend to stall on process before they stall on technology. The pro and con sides each cite “consensus,” and they mean different bodies. Whatever Búzios decides, the argument is likely to move from whether Contracts are good to who gets a veto, and compiler vendors will keep shipping their own implementations in the meantime, as GCC 16 already has.
For anyone writing C++ today, nothing breaks. Your compiler still compiles. The cost is planning: a year of uncertainty about which features arrive together.
The full national-body comment report isn’t due until mid-January 2027, so nobody outside the room has read the complaints yet.