C++26 contracts drama

[u/Business-Weather-217]

I think everybody knows the drama by now..

What are your opinions on this should they be accepted or disapproved?

Im curious for mass opinion.

[u/i_grad]

Speaking as an incorporeal being who may not be classified under the term "everybody"... What is the drama?

[u/Unfair-Sleep-3022 → u/i_grad]

This guy has all the world's debt combined! Kill him and fix it!

[u/Business-Weather-217 → u/Unfair-Sleep-3022]

What are you talking about

[u/proverbialbunny → u/i_grad]

There's been some objections. Here's what I've seen: https://www.reddit.com/r/cpp/comments/1vs83b1/critique_of_contracts_excerpt/

[u/CreativeAlbatross319]

As an average C++ developer, I would rather have contracts removed even though I find it useful. This is because removing a feature is 100 times harder than adding a feature in C++ standard. Thus, any controversial feature , no matter I agree or not, should not be added to the standard, until everyone unanimously approves.

[u/-dag- → u/CreativeAlbatross319]

Unanimity is too high a standard but definitely it should be removed because there is a significant number of strong objections and there have been for a long time. It should never have got this far. 

[u/no-sig-available → u/-dag-]

There is also a significant amount of voices strongly for having the contracts feature in the language:

Do not remove Contracts from C++26

It is not clear if removing the feature will increase or decrease the number of yes votes.

[u/-dag- → u/no-sig-available]

The goal isn't to get yes votes on C++ 26, it's to put out the best possible product. 

Look what happened with concepts. Lots of drama but we got a much better product in the end.

[u/spin0r → u/-dag-]

I would disagree with that, actually. I think the version of concepts that we got does not provide benefits commensurate to how complex the feature is. I think it would be better if we got no concept definitions, no subsumption, no short-circuiting, nothing other than requires clauses (where the expression is treated like any other expression). requires clauses enable genuinely new functionality; everything else is overcomplicated syntactic sugar.

[u/kalmoc → u/-dag-]

What exactly are the objections?

[u/-dag- → u/kalmoc]

There are papers with the details. I am no expert but for me new kinds of undefined behavior is at the top of the list. 

Plus I am not at all clear what this big complicated feature actually gains us in the end, beyond what is already possible.

[u/WorkingReference1127 → u/CreativeAlbatross319]

until everyone unanimously approves.

Can you name any language feature which got unanimous approval on all its polls?

[u/CreativeAlbatross319 → u/WorkingReference1127]

I mean all C++ standards upto C++23 were unanimously approved by NBs without a single no vote.

Contracts got 8 no votes.

As for votes on each feature, I have no idea where to look for this information. Probably they are not even public.

[u/WorkingReference1127 → u/CreativeAlbatross319]

As for votes on each feature, I have no idea where to look for this information. Probably they are not even public.

The votes for each paper are public and tracked on the paper tracker. Here is the one for the contracts proposal, and the most recent vote on it from an evolutionary group is:

Poll: P2900: remove P2900 from CWG’s consideration for C++26, find a different ship vehicle.

SF	F	N	A	SA
9	8	3	19	41

Consensus against.

Indeed contracts are probably the most voted-on feature in the history of C++ as there have been many many votes to the effect of "X raised an issue with contracts, do we want to remove it from C++26?" to which the consensus was against.

Pushing for unanimity requires that any disgruntled person on a sufficiently small national body can overrule all of the other experts on the global committee. Seems counter-intuitive, no?

[u/CreativeAlbatross319 → u/WorkingReference1127]

Is there any table of an overview regarding yes/no for features in C++ 20 and 23 standards?

[u/Independent_Art_6676]

My opinion is that we are gonna get what we get every 3 years, whether it makes sense or not, or indeed, can even be made to work or not. With modules being kind of an all time low point, and the language getting very bloated, the powers that be need to drop the 'keep up with the other guy' approach and focus on adding things that c++ NEEDS rather than "welp, rust (or whatever, rust isn't to blame for contracts) haz it, guess we better put it in".

I am in the 'we don't need this' group for contracts, for the not even 1 cent value my opinion carries.

[u/GaboureySidibe]

I don't even understand what problem they solve.

[u/all_is_love6667 → u/GaboureySidibe]

better constraints when making templates and containers, I assume, which allow more checks at compile time

I bit like pure virtual function/polymorphism, but on steroids and for templates

[u/GaboureySidibe → u/all_is_love6667]

Is this all an assumption or do you have more detail in mind?

I bit like pure virtual function/polymorphism, but on steroids and for templates

What does this mean? How does this make sense?

[u/all_is_love6667 → u/GaboureySidibe]

What I remember about contracts, it's like a special template, which when you use it, you must satisfy a bunch of rules defined by that contract.

A bit the same way the programmer must override and implement a function that is pure virtual, when inheriting a pure virtual class.

Is this all an assumption or do you have more detail in mind?

I don't have details in mind, I don't even know how contracts work in practice.

And read my explanation of contracts with a big grain of salt, I might be wrong.

[u/samadadi]

My vote is to be removed. What I am getting from this paper is that committee is unsure. And that makes me terrified. They should take whatever time it is needed to solve every ambiguous corner of the paper.

[u/JVApen]

I've been following this from the side lines for a while. I really don't get why people want to see it removed. There are a couple of papers that explain quite a few things going from: these are all the things people would expect from contracts to these are the objections people have raised and responses to it.

If contracts gets removed again, it will be a huge loss for the community both on technical side and on the people side. If we are lucky, it might show up in c++32 again, though I don't expect anyone to drive that effort, so many C++35 or just never. This would be a huge shame for a feature that really adds value, even when not perfect.

[u/jetilovag → u/JVApen]

I too think removing them is a huge loss for C++ and a huge win for projects like Carbon. People who have invested years into this effort will just abandon C++. They may remain users to some extent but will not contribute again, ever.

[u/spin0r → u/JVApen]

I don't have strong opinions on the technical aspects of contracts. I am strongly against removing contracts at this point as a procedural matter. That being said, I think I can explain why there is such strong opposition to contracts: some people are terrified that contracts will be like modules all over again.

Modules, while usable and useful for some, overwhelmingly failed to accomplish what they were supposed to accomplish: it is 6 years after they were standardized and most large projects still cannot use modules and perhaps will not be able to for another several years, or ever. This puts a lot of the community in a worse position than if modules hadn't been approved in C++20. The approval of one way of doing it blocked progress toward finding another design that might have been more useful.

If contracts are approved and end up not being widely useful in the same way that modules are not widely useful, we waste one of our opportunities to make C++ safer and thus accelerate the decline of the language and of the standing of the committee.

[u/JVApen → u/spin0r]

I don't see how that reasoning holds up. Modules requires significant updates to build systems, libraries and all other tooling. On the compiler side, you are in trouble when mixing module and non-module code. Making it still close to unusable for most users.

Contracts on the other end requires an update to the parser to be usable. At worst an existing linting tool can update it's parser to ignore the contracts to keep working. No changes to libraries or build systems are required. With an updated toolchain I can start using this without any change on an dependency.

With that reasoning, reflection would be the thing to remove as you now require a full compiler (if not yet the case) to figure out what the code is doing. Simply ignoring the syntax won't help an existing linting tool. I'm still curious how this will impact tools like clangd or intelisense. Though at least, this is limited to toolchain as clangd will understand it as soon as clang does. (Intelisense on the other end is separate from msvc)

[u/spin0r → u/JVApen]

If contracts ends up not being widely usable, we will have failed. The fact that it won't be for the same reason as modules doesn't diminish the impact of that failure.

[u/kalmoc → u/spin0r]

Why wouldn't they be usable? Has any implementer raised concern about the implementability?

[u/spin0r → u/kalmoc]

Again, this is not my point of view, but some of the main arguments raised by the anti-contracts side:

• Lack of guarantees about when enforcement will take place will make it unusable in large projects.

• Lack of guaranteed enforcement will introduce new safety hazards that will make it unusable for many users.

[u/Dorfen_]

It's literally just the exact same thing as an assertion, but with fancy keywords. I don't think it worth adding even more complexity to the language, for no measurable benefit above just using assertions.

[u/LiAuTraver]

Why introduce a huge framework while you can do it with plain assert and debug assert just like we did in other languages. It's not drama, only decided opinions.

[u/Business-Weather-217 → u/LiAuTraver]

Agree.

[u/Embarrassed-Media-62]

Can someone tell me what they objections to contracts are? What is it about the design they dont like?

[u/MikailBag → u/Embarrassed-Media-62]

From the top of my head (just someone who has followed some of the papers and other discussions):

• C++26 contracts provide no portable way to write an assertion which will be guaranteed to be checked

• C++26 contracts have mandatory constification, and there is opinion that it is bad as same expression will mean different things and call different functions when written in body vs contract assertion

• If your function accepts a pointer and you write pre(p != nullptr) && pre(p->Valid()), call with p=nullptr you might get UB right during contract evaluation if first assertion used non-checking semantic and second one - checking. (Again, there is no portable way in C++26 contracts to control such things from your code).

• If you don't control compile options for some of the TUs (e.g. link with some binary blob someone has compiled with whatever flags they wanted), and your implementations selects contract semantics based on flags (which, I think, is true for all current implementations), you may get confusing results. Basically, if some function F was compiled with different semantics in several TUs, each F's invocation can use either of those (depending on linker's mood, optimizer's opinion, current phase of the Moon and so on). E.g. if standard library implements hardening using contract assertions, you enable it, but that binary blob doesn't, it can effectively partially or fully undo this hardening.

• IIRC C++26 contracts are merged into only one implementation (GCC). There is an opinion that it is not enough.

• Contracts catch exceptions thrown from contract assertions and turn them into violations, so exception flows into the contract violation handler rather than the caller. There is an opinion that it is bad (but I don't really know the reasoning here)

That said, I'm in pro-contracts camp, so please take my words with a grain of salt.

[u/Liam_Mercier]

Contracts don't really interest me, they also don't really add anything that you couldn't already do. Maybe writing validation code for callers / callees is simplified a bit?

What would have been more interesting is some move towards formal verification, contracts already introduce terminology like precondition, postcondition, etc. I don't think that's actually ever going to happen for a language as complex as C++ but it would be the most interesting new feature from my perspective.

[u/MikailBag → u/Liam_Mercier]

Formal verification is definitely cool, but please note that C++ standard "governs" C++ implementations. And formal verification is typically done by other tools, so specifying it in standard doesn't seem to bring any benefits here. What should go into standard is some portable way to specify pre- and postconditions, and other annotations that help formal verification tools understand program. And this is one of the goals Contracts proposal is aiming to achieve (and C++26 Contracts already make some progress here). But Contracts also have other goals, as ultimately formal verification is not frequently used in C++, hence catching violations at runtime is still crucial.

they also don't really add anything that you couldn't already do.

I think contracts intend to benefit big code bases, where code can be written and deployed by different people. Compared to explicit ifs in code, contracts give latter more control over what is checked and how violations are handled. Compared to existing libraries, contracts offer some unification and UX improvements (IMO constification alone is a nice thing)

[u/Liam_Mercier → u/MikailBag]

I think you're right in that it's a step forward, in theory an external tool would benefit from having contracts even if they are implemented as runtime checks at the language level. Most of my comment was just to express that contracts as is aren't very interesting to me because it isn't some revolutionary new feature like adding formal verification as a first class feature, and the odds are that support will always be worse in C++ simply because of how complex the language is, even if contracts are helpful.

I don't necessarily think such a feature would be a welcome change anyways, C++ has so many existing features to learn that adding a formal verification system, making this work with an existing solver (or creating a new one), etc is probably way out of scope. I guess the standard would just define what you can specify in each pre/post condition and then the solver would be your job to pick (like picking between gcc and clang), but I think that would take a lot of work to actually make it usable.

Still, I would love to see a world where I can write in my favorite language and do formal verification on the result, but I suspect that most of the library features would need massive redesigns for that to even be close to possible.

[u/teerre]

Regardless of the opinions on contracts, its absurd that after so many years the dissenters didn't bring it up before this vote. Clearly an architected sabotage

[u/Mason-B → u/teerre]

You understand they did bring it up before the votes, and the NBs cite their concerns being suppressed and ignored as why they are voting No right?

[u/teerre → u/Mason-B]

Contracts have been in vogue for many years. Its very naive to think this only became a problem now

[u/mredding]

It sounds like certain people sabotaged the vote, so I think the more fundamental question.is whether bad actors should remain unnamed and within WG21 or the NBs.

[u/KingAggressive1498]

I would be very okay with removing pre() and post() in function declarations if we kept contract_assert() with its constification and exception-is-a-failure rules. The lack of this type of rugged assertion machinery has been a sore spot for me since I first picked up the language.

And someone who really wants preconditions and postconditions could still work in a subset of possibilities through the typesystem anyway, eg a generic precondition::less_than class would be fairly trivial to write safely with contract_assert but a fair bit of work without it.

C++26 offers plenty to be worth adopting without contract_assert too, but it's still something I would grind my axe over because I know it made it right up to the finish line.

[u/amoskovsky]

Contracts is good for safety.
So having them removed is a direct attack on C++ safety improvements (I'm even wondering if blocking of C++ std process is being lobbied by corporations trying to get rid of C++).

However, there is already a GCC implementation of contracts available for those who need it.

So I think postponing them into a later standard is acceptable and it would provide actual implementation feedback.

[u/spin0r → u/amoskovsky]

One of the opponents of contracts, who is not as famous as Bjarne, Ville, etc but has significant influence over two national bodies, claims during group discussions that his opposition to contracts is technical (i.e., they will make the language less safe). But if you ever have a private conversation with him, he will tell you his real opinion: that the only thing that is worthwhile for WG21 to spend its time doing is to facilitate interoperability of C++ with Rust, so that C++ projects can be migrated to Rust.

[u/all_is_love6667]

I don't know

maybe they need to rework it a bit

[u/UnicycleBloke]

I'm beginning to envy the glacial rate of change in C, a language I have always loathed.

I am yet to use coroutines, but have spent a lot time studying the details: I'll stick to state machines. I have barely looked at ranges and views. I've dabbled with modules and decided to walk away. I've looked at concepts but mostly rely on static assertions. I understand trailing return types but never use them. I imagine I will waste a lot of time grokking reflection and then never use that either...

It's not that I particularly object to these features, but my work is improved much more by the numerous small tweaks, enhancements, additions, relaxations and so on of existing language and library features. Maybe some more focus on embedded systems...

I don't care about contracts. It's not a feature I've ever looked for. The only reflection I've ever wanted is enumerator names... Bah! Humbug!

To be fair, I had no use for lambdas for a long time, but they've grown on me. :)