[1] I'm still in the C camp, and don't write C++, but contracts seem of dubious value given the lack of guarantees about whether something can be compile-time vs runtime enforced. It's sold as a safety thing but in reality it seems the value is more about optimization & performance and potentially could cause security issues of it's own.
It seems the lead author and champion is a guy from Bloomberg, of all places.
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.
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.
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++ principals. 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.