C++26 fails ISO ballot over Contracts, tested in GCC 16

The draft of C++26, the next version of the C++ language standard, failed its ISO ballot in October 2026. The fight that sank it is over one feature: Contracts. The C++ committee, called WG21, meets in Búzios, Brazil, from November 16 to 21 to decide whether to cut the feature, move it out, or vote again. The result decides whether C++ programmers get Contracts in this standard at all.

What happened in the C++26 ballot

The ballot was on the Draft International Standard, the last full vote before ISO publishes a standard. Each country's standards body votes. The Register reported 13 votes in favor, 9 against and 12 abstentions. ISO allows no more than 25% of the votes to be negative.

Other accounts give a slightly different count. A blog post by Mond, and an HFT University analysis, both rely on figures posted by committee member Robert Seacord. Those say 12 of 20 voting members approved, short of the 14 needed for two thirds. They also say 9 of 22 bodies voted no, where at most 5 are allowed. HFT University notes that the official result is not public yet. Seacord's post put it plainly: "Balloting has completed for C++26. Unfortunately it was Disapproved."

HFT University lists the countries that voted no:

Vote	Countries
No	Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain, Sweden
Abstained with comments	France, Ireland
Abstained	Poland, United States

Why national bodies voted against Contracts

Contracts let a programmer write checks into a function's declaration. A precondition, written pre, says what must be true when the function is called. A postcondition, written post, says what must be true when it returns. A contract_assert statement checks something in the middle of the code.

Bjarne Stroustrup, who created C++, leads the opposition. "The P2900 contracts and extensions aim to change the nature of C++ and are an existential threat to C++," he said, according to The Register. Andreas Fertig, a committee member, defended the design: "The topic has been worked on for years and has received a majority vote multiple times in its current form."

Mond's analysis says national bodies from at least seven countries asked for changes that were rejected. Some wanted Contracts removed. Others wanted checks that could not be switched off. At least four asked that the hardened standard library, which adds safety checks to library code, not depend on Contracts. The committee kept that link.

What WG21 can decide in Búzios

The Register lists three options. WG21 can remove Contracts so the rest of C++26 ships. It can move Contracts into a separate Technical Specification, a side document outside the standard. Or it can make a minor revision and vote again.

Two papers argue each side, according to Mond. P4433R0, "Do not remove Contracts from C++26", warns that removal would also mean rewriting the library hardening text. D4420, "Do Remove Contracts From C++26" by Vinnie Falco, argues the opposite. If the standard slips, The Register says its formal name may become ISO/IEC 14882:2027.

Tested: C++26 Contracts in GCC 16

GCC's status page lists Contracts as available from GCC 16. Clang's status page says "No". In a Tech AI Wire test on macOS 26 with GCC 16.2.0 in an ARM64 Linux Docker container, a small program called safe_div(10, 0) with this check:

int safe_div(const int a, const int b)
    pre(b != 0)
    post(r: r * b <= a)
{
    return a / b;
}

Each build used g++ -std=c++26 -fcontracts -O2 plus one -fcontract-evaluation-semantic= mode:

Mode	What happened on safe_div(10, 0)	Exit code
enforce (default)	Printed the violation, then aborted	134
observe	Printed the violation, kept running, printed 0	0
quick_enforce	Aborted with no contract message	134
ignore	No check at all; printed 0	0

The ignore and observe builds both printed 0 for 10 divided by 0, a meaningless answer. The violation report names the file, line and condition: contract violation in function int safe_div(int, int) at contracts.cpp:4: b != 0.

Two build errors are worth knowing. The first try used plain int a, int b, and GCC refused: "a value parameter used in a postcondition must be const". A build with -std=c++26 but without -fcontracts compiled, then failed to link with an undefined reference to handle_contract_violation.

The test also counted machine instructions in the compiled function, with only the precondition. A hand-written if (b == 0) std::abort(); took 6 instructions. quick_enforce took 11, and enforce took 15. With -fno-contracts-conservative-ipa added, they dropped to 6 and 9. GCC's documentation says that option controls whether the compiler may optimize across inline function bodies. HFT University reported the same pattern on x86 processors.

What this means for developers

Do not plan a codebase around standard Contracts yet. The feature may be cut, delayed or changed in Búzios, and WG21's report after November 21 will say which. Code written today for GCC's -fcontracts could need edits.

If you test GCC 16 anyway, pick the mode on purpose. ignore and observe let a failed check run on, so they suit logging, not safety. Mark parameters const when a postcondition reads them. Compare quick_enforce with a plain if in your own hot paths before you trust its cost. If you rely on library hardening, watch whether it stays tied to Contracts after the meeting.