Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.
Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.
Rust tries to solve this by having basic addition panic in debug, while silently-but-consistently continuing in production: overflow is considered a bug, but it is at least not a platform-dependent bug.
If overflow is expected, then there's checked_add to detect it and fail in a friendly way, saturating_add / wrapping_add / carrying_add for specific overflow behavior.
Finally, if speed is crucial and overflow is either impossible or you don't care about the outcome whatsoever, there's unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".
You can still do everything you can with C. It it just an explicit choice, rather than an implicit platform-dependent mechanism you might forget about.
Just like for signed integers in C the {integer}::unchecked_add is Undefined Behaviour if overflow occurs. So that's not "whatever the machine feels like" it's much worse.
This is an unsafe function, so you're expected to write a SAFETY rationale for the unsafe call, and that's your opportunity to justify to a future maintainer why you were sure this addition never overflows. If you find yourself struggling to justify that belief it probably means you should not have used this function.
If you're going to write guard code for overflows, and use that to justify the SAFETY claim, why not use the existing functions for that? Clippy will suggest this in many cases because it's less likely you will blow your own foot off.
At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.
All I said is that you can remove undefined behavior from signed overflow without having to introduce checks to every arithmetic operation and without having to specify any particular behavior or outcome. The technical term for this is "unspecified behavior" and the consequence of making overflow unspecified behavior is that the consequences of overflow, while still unspecified, must be bounded in space and time, unlike undefined behavior whose consequences are not required to be bounded in either space or time.
You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.
The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.
Contrary to Contracts, which at least managed to get consensus in WG21, I very much doubt that Profiles will get consensus.
I've noticed that Bjarne Stroustrup is being subjected to a smear campaign, when things are far simpler and far less conspiratorial than they are making out to be.
There are indeed papers demonstrating that not only is the current proposal for contracts broken but it also fails to adhere to core C++ principles. They have been published since at least 2017. Contracts aren't new, nor the problems they introduced. They've been routinely removed from C++ standards, and so far the proposal wasn't fixed.
So ask yourself this: why was a notoriously broken feature forced into the proposal when it was clear it wasn't going to pass?
From an outsider's point of view, I see this from a different perspective. Contracts proponents tried to use bureaucratic tricks and threats of abnormal processes to force a broken feature they knew for years that wasn't supported or passing the smell test. And now that they saw their efforts thwarted , the complain that their plan failed and they have opposition?
I mean, there is even a paper dating back to 2025 called "contracts concerns" and from 2026 called "contracts fundamental flaws". The C++ standard is a consensus-driven process. Does this look like consensus? Clearly no.
So we have a group of people who ignored the calls that they were pushing a broken feature, but tried to railroad the process anyway and ignore any concern or warning. Then, when they tried to force their way through the process, their bluff was called and their threats failed. And now they are lashing back.
It seems the lead author and champion is a guy from Bloomberg, of all places.
https://isocpp.org/files/papers/P2900R6.pdf
As the story goes, these guys pushing contracts systematically pushed a broken proposal by dismissing criticism with bureaucratic chicanery such as purposely ignoring feedback and criticism by claiming that if other people voted in favor of their proposal then they shouldn't need to bother with feedback from those who opposed.
I mean, look at the reaction. It's not technical. It's not principled. It's bureaucratic and grounded on petty politics, and dismissing yet again a failure to gather consensus as personal attacks and a political issue.
From what I've seen of the story, the opposite is true. The people opposing contracts are the ones who have been engaging with bureaucratic chicanery to try to rip it out of the standard. In the discussions within the committee, they've been given every opportunity to make their case and had their arguments heard, even when those arguments failed to persuade anyone and are simply relitigated again and again in subsequent meetings as if they're new. In at least one national body, the anti-contracts people used the bureaucratic process to change the vote of the national body.
Two papers that both have the same authors, one of whom is Bjarne Stroustrup.
Why are you convinced the narrative is that contracts are actually broken and unfixable instead of a few influential people just really hate it for reasons they have been unable to convince anyone else are valid?
Have you read the "contracts fundamental flaws" paper? Looking at it now, it's hard to take it seriously. The biggest complaint seems to be that the marketing of contracts is wrong. Literally: "We would welcome a contracts design that is simple, and “marketed” as just a debug aid, rather than a safety feature."
It really does look like Bjarne is convinced that profiles are the future for C++, and contracts makes it less appealing to get there. And that's something that reasonable minds can just disagree about without it being a conspiracy of some kind. WG21 doesn't seem to believe that profiles are an anytime-soon-if-ever feature, and contracts provide immediate benefit that justifies any future complications with profiles.
Stroustrup's objection of subversion of, and politicization of the "consensus" process seems pretty darned reasonable to me.
And having two major compiler implementers (Clang and Microsoft) among those opposed to the proposal seems like a very poor sort of consensus to me.
The decision to defer how contracts on virtual methods work until C++29 strikes me as particularly horrifying, and renders the feature completely unusable precisely at the point where it most needed (PIMPL classes where public methods are pure virtual, with implementation provided in a private derived class).
And reminds me of c++20 coroutines, for which we are still awaiting a usable implementation. I made the mistake of actually writing a wrapper library for c++ coroutines. A great feature, but only heroically usable in its c++20 incarnation. (I actually did use it in project, but was left wondering why anyone would actually release THAT feature without a supporting class library). Implementation details were shocking, and awful, and insufficiently specified. And I would be completely amazed if my wrapper library continues to work with C++26.
God willing, C++26 will provide an implementation that allows us to sanely use coroutines in message pumps and thread pools soon (such a great feature!), if the standards committee, God Willing, takes the right and good and sensible path of removing contracts from C++26 so that we can get the structured concurrency library.
All in all, I can't help wondering whether the C++ standard doesn't need "Experimental Features" like Java has. It's certainly interesting to see how The Who Must Not Be Named (Oracle) uses experimental features, some of which have existed in experimental status across four or five Java releases. C++20 coroutines and contracts would have been perfect candidates for "experimental C++ features", that can be tested and hardened and have breaking ABI changes made as necessary and appropriate.
> welcome a contracts design that is simple, and “marketed” as just a debug aid
The operative word would be "simple". It's hard to imagine that the feature would require 56 (!!) pages of specifications if the constness rule were omitted. Who the heck ordered that!!??
The better question you should ask is: who determined that number and put it in their paper with a straight face?
Yes, the section on wording in P2900 is physically 56 pages. That's not 56 pages of new wording though.
For those unaware: Wording is always presented as a diff to the working draft. Apart from new sections that have to be added for contracts, those 56 pages replicate existing pages of the draft verbatim as context for their changes, which often boil down to: adding a bullet point to a list (e.g. extending the list of keywords), adding a sentence to a pre-existing paragraph (e.g. extending the syntax for lambdas), etc.
You could probably condense the wording down quite a bit, it would be harder to follow what is going on with the changes, but apparently that's what some people who just count page numbers would prefer.
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.
Stroustrup is 75 years old. This is not only hard to believe because of his age, but also because it requires that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views. Weird, man.
Not weird if they're mostly from different continents.
When I saw him a year or so ago he said he wasn't happy with how things were going, but never alluded to a coup. But it's his language, so good for him.
It most definitely is not and hasn't been in decades.
A major problem is that some people still put his views on a pedestal, acting like he has a clean track record with his ideas, which he definitely has not - no language designer has ...
...He has the power to do this? And for which elections, exactly? The main go/no-go votes are the ones at the big meetings and I'd imagine there's not a lot of room for scheduling shenanigans there.