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.
The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts.
I think the risk is that C++ contracts become an evolutionary dead-end that hang around forever in code bases because they were standardized. It wouldn’t be the first time this has happened.
Phrased differently, contracts are to concepts what assert is to static_assert.
Contracts notionally offer the ability to lift some runtime assertions to compile-time. That is how it was sold. Except they don’t in practice.
Meanwhile, concepts + constexpr if used artfully deliver that in practice, including for many cases that contracts were supposed to solve.
I push all verification to compile-time to the extent possible.
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.
Spoiler alert: The option described as "the sort of leadership failing that I pray we can avoid" is what ended up happening.
But they say this is the first case where a DIS failed during the standardization consensus process. Why is that?
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.
SIMD on different silicon is incompatible at layers of abstraction far above the codegen manipulation a compiler can do.
There were no "dirty tricks". The C++ standards committee works by a vaguely defined "consensus", which requires more than "the majority rules". Contracts got added to the C++26 draft. Then there was consensus that Contracts needed to be fixed, but they could never get consensus on any particular fix. So they cruised along relatively unchanged.
In the end, the only way to NOT accept a marginal Contracts feature was to vote down the full language spec. Now they'll regroup and decide how to proceed.
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.