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.
One of the best features to be added to C++ in many years.
C++ contracts are an attempt to bring C asserts into the C++ age. The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts. If you really care about this type of thing, you probably already have a custom C++ assertion framework that is at least as nuanced if not more.
The promise of C++ contracts is that they can aid formal verification, which would be great. As delivered, it can’t do much more than was already possible, which will inhibit adoption.
Phrased differently, contracts are to concepts what assert is to static_assert.
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.
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.
And we have no idea what AI systems will be doing in 2027.
I pretty much do all my low level vibe coding in Rust. Is C++ still relevant? What prevents Rust from completely supplanting it?
Rust is in tenth place with 1.44% ranking, it's rising fast but still has a long way to go before it catches C++.
I'm not going to speculate about why Rust hasn't yet supplanted C++ but I will say I don't find it surprising.
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.
Personally, I think it is still relevant. Many people thought Kotlin could overtake Java, Java reinvented itself with new initiatives/features and was saved from becoming irrelevant.
Rust also has the LLM advantage which is where I think the "if it compiles it works" nature of Rust is easier for manual changes and maintenance when needed.
EDIT: Would love to know why people are so angry about that?
So most people will read your view as hypocritical/misinformed.
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.
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.
- 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++?
Support for contracts is fairly broad and spans numerous organizations.