> They will be another modules disaster (...)

This is the kind of puerile remark that erodes the credibility of this sort of personal opinion. At most, modules can be criticized for slow uptake from compiler and tooling vendors.

Slow adoption is a trait of C++, a field which is notoriously conservatice and where some corporations are still stuck using pre-module C++ versions such as C++14 or C++17.

In the meantime, the existing support for modules already boils down to shipping binary + module.

Back to Contracts, this is literally something that is only relevant to those who actually use them. For people like you who made a decision to not use them, you can still lead a life in blissful ignorance and disregard contracts altogether.

But here you are, trying to frame them as a disaster. It goes to show the depth of your observations and your credibility on the matter.

That shows how much you know modules, what is your experience with header units?

Modules can be critized by having been added to the standard without field experience, from the two implementations, Apple's clang module maps, and Microsoft's modules prototype that was the base of C++20 proposal, none of them is what was standardised in the end.

The standard also was ratified without any feedback from tool vendors, which have had to come up with their own solutions outside the standard.

IDEs still struggle to support them.

So no, it isn't "already boils down to shipping binary + module."

Contracts are much worse, because beyond some prototypes that the community could hardly provide any feedback, all the issues that have been raised regarding compiler toolchains, and shipping binary libraries, national bodies request for comments have been had waved as not being a big issue.

Yeah it goes to show how some want contracts at any cost.