C++26 faces major delays after ISO ballot fails over disputed Contracts feature

The next major update to the C++ programming language may miss its planned release window. In October, the Draft International Standard for C++26 failed to pass an ISO ballot. The vote received 13 approvals, 9 rejections, and 12 abstentions. Under International Organization for Standardization rules, negative votes cannot exceed 25 percent, meaning the proposal fell short.

The battle over Contracts

The core dispute centers on a security mechanism called Contracts. This feature lets developers define preconditions, postconditions, and assertions in code. These checks verify that specific requirements are met, preventing errors that cause undefined behavior. Programmers have attempted to integrate Contracts into C++ for over ten years, including an effort dropped from C++20.

Critics, including C++ creator Bjarne Stroustrup, strongly oppose the current proposal, designated P2900. In a paper published in August, Stroustrup and other opponents argued that the plan introduces complexity, bloat, and messy code, labeling it an existential threat to the language. They also suggested that Contracts would be better delivered as a library rather than built into the core language, noting it could hurt performance.

Supporters push back against this view. Andreas Fertig, a member of the standardization committee, argued that rejecting the feature after years of development and previous majority votes damages trust in the standardization process. Meanwhile, outside security pressure continues to grow, as many developers migrate to languages like Rust to avoid security flaws.

Next steps for the standard

The failure of the ballot makes it possible that C++26 will be delayed until 2027, which would change its informal name to C++27. The ISO C++ working group, WG21, is meeting in Búzios, Brazil, to resolve the stalemate.

Technical leaders are weighing several paths forward:

• Removing Contracts entirely from the standard, though this requires unraveling library changes already in place.
• Spinning Contracts off into a standalone technical specification for further testing.
• Making slight revisions to the current text before holding another vote.