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.

▲

maccard a day ago | parent [-]

> The current contracts are not good enough for anybody who wants them -

This is a recurring pattern across large changes to c++. Modules and coroutines both are great examples of this.

> but it is good enough that they can start figuring out the details of making all the different factions happy.

I don’t think there’s really a plan to make the factions happy, there’s a plan to get X in, say it’s in and then ignore any actual criticism in favor of “it was the best we could do” while pointing at the other groups for not accepting the massive flaws.

▲

MFHava a day ago | parent | next [-]

>> The current contracts are not good enough for anybody who wants them - > This is a recurring pattern across large changes to c++. Modules and coroutines both are great examples of this.

Coroutines are ready since C++20, there is some stuff missing in the language (`for co_await` being the most obvious thing), but the feature is useful as is...

▲

bluGill a day ago | parent | prev [-]

The only complaints I've heard about modules that is real is it took some time to be ready. Everything to use is from people who don't use C++ and want to pick on it.

▲

maccard a day ago | parent [-]

I’ve written c++ every day for the last 15 years. The problem with modules is they’re the meeting point of a pile of decisions (or lack of). Modules have been talked about for longer than I have been programming and I still don’t know of a project that is using them that has seen a compile time improvement.

You might argue that modules aren’t the solution to compile times, but for a very long time they were. Now they’re a better way to structure code, except they’re not really backwards compatible. That dorsnt matter because the committee doesn’t consider that bit at the same time refuses other changes that may have similar impacts.

I think c++ is caught between a rock and a hard place. There’s a group that wants only existing behaviours standardised, and another that wants the language to be a force that brings the ecosystem with it. What we get is the latter group proposing changes that look like progress, but no (or limited) real change happening due to the first group, while the first group are forced to have the language change almost for the sake of it to placate the latter group.

	▲	bluGill a day ago \| parent [-]
		Modules have just reached to the point where the tooling is all ready for people to adopt. Right now we are seeing the early adopters start to use modules. We are still waiting to see what they report. They are certainly a major change to how you program C++ and so adoption is going to be slow - retrofitting something new to an existing project is always hard. I still have some C++98 code that has naked new and delete. I'd love to get rid of it but it would be a long painful process to refactor and it's not worth it when the code has been stable for decades. I'm still hopeful that they're a useful thing for the various benefits they should provide, but only time will tell. People who claim that modules have failed because we haven't seen benefits yet are just ignoring the reality that change is going to be slow by nature.