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.
Huh? Concepts are types of types. Contracts are fancier, structured runtime assertions. What does one have to do with the other? They're nothing alike.
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.
Agree. There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming (also, it has better error messages). But the argument really falls apart when you review WG21's track record for other features.
Like for example, Coroutines were billed as an easier way to write concurrent code, but personally I think it completely failed and ended up being hopelessly complex and confusing. Modules are the same - superficially they make things simpler, but when people actually go to adopt it, the details are so complex that nobody bothers.
99.9% of all system code in the world is still written in C/++. It runs your Java, C#, Javascript, Python, PHP, basically every production language that isn't Go or Rust. It runs the two most popular game engines in the world. It runs your phone, server, and laptop, no matter which of any you use. It runs your car. It runs almost every embedded and industrial application on the planet.
Is it still relevant, JFC. The way people on this forum manage to sequester themselves from reality. Let me reverse the question: is Rust relevant? Mozilla developed Rust, abandoned their Rust browser, and only 10% of Firefox is written in Rust. Maybe 1% of modules in Chrome and Linux are written in Rust, if that. And what of Rust applications written from scratch? Can you name ten applications that have, say, exposure to more than 100,000 users? Impossible mode: they can't be developer tools only used by other developers (uv, ripgrep, etc.), they must actually be applications used by enterprises or consumers.
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.
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.
Yes that's right, and from following some threads on reddit about this, he used some really dirty tactics to get it to fail, like scheduling certain snap elections to happen with very short notice at times of the day when people who would oppose his point of view would likely be asleep.
The issue that caused this to be voted down is often seen as a memory safety solution (not something I personally 100% agree with, but thats a broad view). And the rest of this release includes other memory safety work. And it was voted down and delayed for apparent political reasons (again not a view I agree with).
So most people will read your view as hypocritical/misinformed.
It could also be read as a straight up attack. Basically, a way of saying “why not follow Rust“ without having to say the word Rust.
I think it was a fair question. As someone who doesn’t follow C++ I really don’t know what else was in the proposal. It’s nice to hear there is memory safety stuff.
You'll find plenty of info if you search for anything like "c++ contracts" [0], but the short of it is that they're just pre/post conditions on functions. Slightly improved assertions, basically.
cppreference is often a bit too technical for its own good :)
But I think there's a broader issue which is that if it took me multiple searches to find a good-enough visual "pitch" for what contracts look like in practice, its champions have not yet won hearts and minds - which brings us to the situation at hand.
Its a very inside baseball article. Contracts is a proposed C++ language feature for improving programmable assertions of program state. E.g. a better c++ version of C's assert function. That in theory will improve both safety and performance by letting people add more complex assertions (e.g. pre/post conditions) to functions.
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.
Perhaps it is, in this case it would be between money and everyone else specifically. Contracts is a pet project of Microsoft and the heavy money parts of the committee. They've basically shouted down the dissenters, hence the effectively unprecedented action of the rubberstamp portion of the process saying they dont think consensus was reached in a kosher way.
No one who developed contracts works for Microsoft. Of the like 20 people who contributed to the feature, 4 of them work for Bloomberg, so you could maybe argue that Bloomberg has a vested interest in the feature, but that's really stretching things.
Support for contracts is fairly broad and spans numerous organizations.
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.
Your comment just made me realize contracts is different from concepts (which are basically bounded genetics, right…?)
Concepts are evaluated compile time and make a lot of TMP more elegant. Contracts are runtime check, akin to assertions.
Phrased differently, contracts are to concepts what assert is to static_assert.
Concepts are for Types at compile time while Contracts are for Values at runtime.
Huh? Concepts are types of types. Contracts are fancier, structured runtime assertions. What does one have to do with the other? They're nothing alike.
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.
Agree. There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming (also, it has better error messages). But the argument really falls apart when you review WG21's track record for other features.
Like for example, Coroutines were billed as an easier way to write concurrent code, but personally I think it completely failed and ended up being hopelessly complex and confusing. Modules are the same - superficially they make things simpler, but when people actually go to adopt it, the details are so complex that nobody bothers.
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.
Maybe a slightly faster std::regex or whatever it's called; apparently it's horrendously slow for no benefit.
Ranges need work as well, there’s lot of opportunity to improve things there.
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?
99.9% of all system code in the world is still written in C/++. It runs your Java, C#, Javascript, Python, PHP, basically every production language that isn't Go or Rust. It runs the two most popular game engines in the world. It runs your phone, server, and laptop, no matter which of any you use. It runs your car. It runs almost every embedded and industrial application on the planet.
Is it still relevant, JFC. The way people on this forum manage to sequester themselves from reality. Let me reverse the question: is Rust relevant? Mozilla developed Rust, abandoned their Rust browser, and only 10% of Firefox is written in Rust. Maybe 1% of modules in Chrome and Linux are written in Rust, if that. And what of Rust applications written from scratch? Can you name ten applications that have, say, exposure to more than 100,000 users? Impossible mode: they can't be developer tools only used by other developers (uv, ripgrep, etc.), they must actually be applications used by enterprises or consumers.
Your Rust very likely runs in a C / C++ environment.
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.
> 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.
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.
Yes that's right, and from following some threads on reddit about this, he used some really dirty tactics to get it to fail, like scheduling certain snap elections to happen with very short notice at times of the day when people who would oppose his point of view would likely be asleep.
Time to cancel the project. C++ acquired sufficient set of features over the years, becoming very PL/I-esque.
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?
The issue that caused this to be voted down is often seen as a memory safety solution (not something I personally 100% agree with, but thats a broad view). And the rest of this release includes other memory safety work. And it was voted down and delayed for apparent political reasons (again not a view I agree with).
So most people will read your view as hypocritical/misinformed.
It could also be read as a straight up attack. Basically, a way of saying “why not follow Rust“ without having to say the word Rust.
I think it was a fair question. As someone who doesn’t follow C++ I really don’t know what else was in the proposal. It’s nice to hear there is memory safety stuff.
Memory safety was solved in 1959 with the invention of lisp
Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?
You'll find plenty of info if you search for anything like "c++ contracts" [0], but the short of it is that they're just pre/post conditions on functions. Slightly improved assertions, basically.
[0] https://en.cppreference.com/cpp/language/contracts
https://www.cppstories.com/2026/cpp26_contracts/ is IMO a better introduction.
cppreference is often a bit too technical for its own good :)
But I think there's a broader issue which is that if it took me multiple searches to find a good-enough visual "pitch" for what contracts look like in practice, its champions have not yet won hearts and minds - which brings us to the situation at hand.
Oh im not a c++ guy but that actually looks pretty awesome because it’s like Hoare logic
Its a very inside baseball article. Contracts is a proposed C++ language feature for improving programmable assertions of program state. E.g. a better c++ version of C's assert function. That in theory will improve both safety and performance by letting people add more complex assertions (e.g. pre/post conditions) to functions.
- 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++?
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.
Perhaps it is, in this case it would be between money and everyone else specifically. Contracts is a pet project of Microsoft and the heavy money parts of the committee. They've basically shouted down the dissenters, hence the effectively unprecedented action of the rubberstamp portion of the process saying they dont think consensus was reached in a kosher way.
No one who developed contracts works for Microsoft. Of the like 20 people who contributed to the feature, 4 of them work for Bloomberg, so you could maybe argue that Bloomberg has a vested interest in the feature, but that's really stretching things.
Support for contracts is fairly broad and spans numerous organizations.