C++26 Disapproved

As someone who writes high-reliability C++ but is completely outside the standards process, I see the issues with C++ Contracts. It isn’t clear that it solves a problem that anyone has in real codebases, especially after C++20 concepts.

If you were already writing high-reliability C++ then the benefits are difficult to quantify. If you weren’t writing high-reliability C++ then it saves you almost nothing over doing the standard idioms of high-reliability C++ that were already available to you at very marginally more cost. It does standardize expression of it in narrow cases but the payoff seems minimal.

Most of what C++ Contracts delivers is a mashup of what you can already do with constexpr and C++20 Concepts. I like reliability features but this feature, as delivered, looks fairly useless if you already use reliability features. A compelling standard would need to make much deeper guarantees out of the box. And the compiler can already see through most compositions of constexpr and C++20 concepts, which is already very expressive.

C++ Contracts looks a bit like a feature that was designed long before current standard features existed.

While I can understand that C++ contracts were met with controversy, contract annotations scoped at analysis time that can be verified by external tools, such as static analyzers, model checkers, or automatic theorem provers, are incredibly useful.

I put together an alternative function contract and invariant mechanism in C using CBMC and custom macros that effectively allows me to perform formal methods in C using compositional verification. The reason why I chose C is because of its relative simplicity and relative ease of building tooling around it. C++ contracts provide some feature parity, and would let me take advantage of some of the features in C++ relative to C.

I hope that the contract proposal is workshopped and simplified so it can be proposed again for a future version. Its current form is unsuitable, but it deserves a second chance with a simpler implementation. Contracts would narrow the safety gap between C++ and languages such as Ada / SPARK.

I get why some folks would like to see contracts in the language, but C++ is also buckling due to the shear complexity that's getting tacked on to it. I'd rather see more proposals such as C++26's "erroneous behavior" that attempts to reign in the language's shortcomings.

Personally I'd like to see C++ chill out on new features and maybe sort out the shitshow that is char8_t and std::filesystem.

> contracts. Put simply, a number of NBs believe that this feature is not yet ready for release.

The ISO National Bodies voted wisely. C++ has had so many ill defined features over the decades and they wanted to avoid yet another one.

I don't have any skin in the game. I've stayed with the C++11 feature set.

> By voting “no,” an established system, one based primarily on trust and respectful collaboration, has been shaken.

I don't get it. If ISO deliberately requires two levels of approval, why should exercising the second level's voting authority be considered a betrayal of trust?

C++ is in a strange position.

If you look at "let's use AI to rewrite xyz in Rust", then C++ has to wonder why it isn't as often mentioned compared to Rust here. I am not saying AI should be the future, but merely compare why Rust is cited here more frequently than C++. That's just one of many other things. Rust also got popular due to crates. How is the alternative called in C++? Barely anyone outside the C++ community knows. And that's also a problem.

C++ isn't going away anytime soon, of course, but when people keep on mentioning alternatives again and again then it shows that the competition intensifed a lot.

C++ should focus into turning SIMD into a higher level language instead of being a giant collection of intrinsics. Avx code is unreadable.

Correct me if I'm wrong, because I don't follow C++ very closely, but based on previous discussions on HN, the opposition paper obliquely referenced in the blog post was presumably Bjarne Stroustrup's, who IIRC had already said he would work behind the scenes to make sure the final pro forma vote to standardize C++26 would fail.

major C++26 features, including reflection, std::execution and library hardening, are also delayed because they were included in the same draft.

Approval of runtime failures essentially failed at runtime

But I'm curious—why did DIS fail this time with C++26? Weren't feature additions in C++ usually plentiful?

But they say this is the first case where a DIS failed during the standardization consensus process. Why is that?

Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?

[flagged]

[dead]

[dead]

Maybe this time could be used to consider memory safety much more seriously.

EDIT: Would love to know why people are so angry about that?

- since you are a part of the voting group, i have a doubt

- let us say tomorrow everyone were to consider removing all unsigned variables across c++

- what is the impact in terms of compatibility for all the old c++ applications which i believe would be millions of them if not billions?

- the reason i ask is they say do not unsigned anything as much as you can because overflowing the bottom below 0 is easy

- has there ever been any consideration to get rid of unsigned xyz in c++?

Time to cancel the project. C++ acquired sufficient set of features over the years, becoming very PL/I-esque.

I feel like this is a bellwether event for society at large. Growing impasses between more and more segments of society. Diminishing trust leading to the inability to reach consensus. Maybe it’s just me though.

I used to be a C++ programmer but I haven’t done it in a few years.

I pretty much do all my low level vibe coding in Rust. Is C++ still relevant? What prevents Rust from completely supplanting it?

I have no idea why anyone would work in C++ in 2026. If I had to work on an existing codebase, I'd just have Claude rewrite it in Rust. It's always been a miserable, awful mess.

At this point, changes to major programming languages have to adapt to a world in which AI systems generate and change much of the code. C++ contracts may be good or bad, but they are from before strong AI coding systems. So it's time to rethink.

And we have no idea what AI systems will be doing in 2027.