C++26 fails its ISO ballot, and contracts are the reason

Something has happened that, as far as anyone can tell, had never happened before: the C++26 draft has been rejected in its ISO DIS ballot, the step before the standard is published. Robert Seacord, convenor of the C committee, announced it tersely on LinkedIn on 24 October: “Balloting has completed for C++26. Unfortunately it was Disapproved”.

Mateusz Pusz, author of the mp-units library and a member of the Polish national committee, explains it in detail in The result of the C++26 DIS ballot, the sixth post in a series on the dispute behind it. Seacord doesn’t think any language standard from ISO’s SC22 subcommittee has ever failed this ballot, and Daveed Vandevoorde, from the C++ committee’s direction group, wrote that no earlier C++ draft had received even a single vote against.

The numbers

A DIS draft has to meet two conditions at once, and C++26 met neither:

It needed 14 votes in favour and got 12; five votes against were allowed and there were nine. Either one alone would have been enough to sink it.

Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain and Sweden voted against, all with technical comments. France and Ireland abstained but also sent comments. Poland and the United States abstained. The comments aren’t public yet: ISO rules allow 12 weeks to publish the full report, so they’ll arrive by mid-January 2027 at the latest.

The reason: contracts

Although the comments aren’t known yet, Pusz is convinced all nine votes against are about contracts, and he has reasons: all the opposition on record before the ballot pointed 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 the previous stage, and one paper, P4238R1, explicitly asked national bodies to vote no over the contracts design and how it had been approved.

Contracts let you write in a function’s signature what must hold before and after calling it:

#include <cmath>

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;
}

pre is a precondition, post a postcondition on the returned value, and contract_assert a check inside the body. Almost everyone likes the idea: it’s documentation the compiler understands and that, if checks are enabled, can’t silently go stale the way a comment can. Pusz puts it well: concepts already do that for the types a function accepts at compile time, and contracts would do the same for values at run time.

The problem is in the details. The code doesn’t decide whether each check runs or what happens if it fails. The draft defines four semantics, ignore, observe, enforce and quick-enforce, and leaves the choice to the implementation; in GCC 16 you pick one with a compiler flag. Much of the argument is exactly that: whether a contract is a check the build may drop or a guarantee the program can rely on. There’s also debate about what can go wrong inside the predicate itself, and whether there was enough production experience before standardising it. Contracts were also removed from C++20, so this isn’t the first time they’ve been left out.

What’s held up

The tricky part is that the rejection doesn’t only affect contracts. Other long-awaited C++26 features are stuck in an unapproved draft with them:

• Compile-time reflection.
• std::execution, the new model for asynchronous programming.
• Standard library hardening, which partly relies on contracts.

What can happen now

ISO rules provide four options after a failed DIS: a new DIS draft with a shorter, eight-week vote; a new committee draft for comments; publishing it as a technical specification; or cancelling the project. None has a date yet.

The next C++ committee meeting is in Búzios, Brazil, from 16 to 21 November, and positions are divided:

• Remove contracts so the rest can ship as soon as possible. J. Daniel García, one of the authors of P4238R1, put it this way: “the short term solution is simple, remove one problematic feature and the rest of the standard can very likely be approved”. Vandevoorde will also recommend removing them, with adjustments to keep library hardening.
• Vote again without changing contracts. That’s what P4433R0 proposes, signed by sixteen contract supporters, who also argue that removing them wouldn’t be quick, because it’s a big change and would force a redesign of library hardening.
• Move them to a technical specification or a separate document, as some countries asked.

Even the name is up in the air. If the standard is published in 2027, Vandevoorde thinks “C++27 would make sense”. It wouldn’t be unusual: C++23 was published so late that it’s officially ISO/IEC 14882:2024. Meanwhile, the current standard is still C++23.

And for today’s code

Compilers implement the working draft, and the ballot doesn’t change what they already ship. GCC 16 accepts -std=c++26 and implements contracts as part of its experimental support, and Clang has -std=c++2c, although its contracts implementation hasn’t been merged yet. Anyone already using C++26 features doesn’t have to undo anything for now, but should know they’re using a draft, and that if they use pre, post or contract_assert with GCC 16, they depend on exactly the part that’s in dispute.

My takeaway

This story seems interesting to me beyond C++. It shows how hard it is to add something as seemingly simple as “check that the argument is positive” to a language with decades of code behind it, many compilers and users with opposing needs: for some, a check must be removable at no cost; for others, if it can be removed, it isn’t a guarantee.

I also keep a reflection from Pusz himself on how these processes work: Poland’s vote almost didn’t exist because quorum wasn’t being reached, partly because some members had changed jobs and weren’t responding. His advice applies to any committee: if you’re on one, vote, and if you can no longer take part, ask to be removed.

And I share his wish: that contracts come out with a better design if needed, but that the rest of C++26 doesn’t have to wait for them.

Source: The result of the C++26 DIS ballot, Mateusz Pusz, Train IT.