One thing that I'm curious about regarding all of this: I thought all of this stuff landed in C++26, yet we are still getting papers like https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p43...
> The C++26 draft has not yet had its final ballot
This is co-authored by Bjarne, and so I'm sure it's not trivially false, but maybe I am just missing some detail. I know Bjarne was threatening to cast a veto of C++26 over this, but I thought he did not?
Anyone who follows the process a bit more than me have some context here?
I haven't followed the contracts discussion particularly closely, but my understanding of the situation is this:
Contracts has the problem that everybody has a slightly different idea of what they want from the feature. What exists today in the draft standard is a messy compromise that has a very broad consensus. However, there are few people who are vehemently against the current compromise and are taking every opportunity to try to upset that compromise.
Now on top of that, there is a separate issue in that the C++ standards committee has started to become too aggressive in adopting new features, and implementers are starting to complain about that. Contracts is one of the new features that is in the camp of the-standard-is-moving-too-quickly, but it's far from the only one and probably not the worst offender, given that there is fairly high demand for contracts. (Constexpr-all-the-things is probably the worst offender from a cost/benefit ratio?)
Currently, the C++26 draft is out to the national bodies for balloting, and the vote in the US national body passed by the thinnest of margins. I haven't heard of the results from other national bodies yet.
Everybody has their own ideas of what they want from Contracts. C++26 contracts are trying to get a minimal system that everybody can agree on. The current contracts are not good enough for anybody who wants them - but it is good enough that they can start figuring out the details of making all the different factions happy.
C++26 contracts are written by people with experience in ADA/SPARK. While we don't have experience in C++ contracts, there is plenty of experience elsewhere. I find it odd that the paper didn't mention Spark at all!
The criticism that it is experimental in all compilers is a fact that can never be anything else. Chicken and egg - nobody will make this non-experimental until it is in the standard. There have many small scale experienements with contracts - enough to agree we want to use this on a larger scale but we need it in the standard first.
bjarne/hsutter and their whole "club" have been (from my admittedly outsider perspective) using the "founding principles" in bad faith in the c++ comittee for a while now, see the strong-arming of safety profiles into the standard while they are in no way workable or anything more than a half-useless solution to anything they claim to solve https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... / https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... / https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p36...
Off-topic: oh wow the most of the Appendix part looks Claude verbatim. Not something I'd expect in a paper from Stroustrup.
I have not been following, but some searching lead me to the conclusion that contracts are currently in the draft, but Stroustrup and some others are loudly saying that is a mistake. See: https://wrocpp.github.io/posts/contracts-dispute/
The current state of C++ next is maintained in what is called the C++ draft.
People (from the committee of experts appointed as national body representatives or invited experts) submit proposals which is essentially merge requests to make changes to the C++ draft. A proposal, by the way of it's changes, can either add a feature to C++ or remove features from C++ (kind of like deleted code).
In each C++ meeting, they have a vote for each proposal in the meeting and decide whether that proposal is allowed to act on the C++, thereby determining if the features gets in the draft (if the proposal was proposing a feature) or if the features is kicked out of the draft (if the proposal was advocating for removal of a feature).
Once a proposal has been voted in the draft, only another proposal can remove that feature from the draft.
Every 3 years, they seal the current state of the draft into a standard and send it for voting to the official ISO C++ committee of national bodies (different from committee of experts we mentioned above). And I think each national body has a veto. (that is the vote has to be unanimous, but not sure here).
At this point, first the National bodies can make comments where they can threaten to veto the standard if their comment is not looked at. Then, the committee of experts can either respond to the comment or follow the comment or do whatever.
The official committee (essentially national body members) then votes and can only approve or reject the standard in the whole. So, if they reject of example C++ next now, there will be no C++26.
The whole process from sealing to actual voting takes around a year or so. In the mean time the committee of experts starts working on the next c++ standard from the sealed state forward without waiting for the committee to ratify the current one.
What Bjarne is doing is that he was threatening to get a national body to veto the proposal so that there is no C++26 at all. So, his point was, either accept his paper as it is (which calls for removal of contracts from the C++ draft before it goes to committee of national bodies), or he probably gets US or Denmark or some NB (not sure which) to vote no on the C++ standard (when it eventually goes to the committee of national bodies with the contracts in it, kind of like throwing baby with the bathwater).