Contracts received a high volume of unfair criticism from unwitting observers, some of which don't even use C++ at all. I think this will be one of those features that is of critical importance and a fundamental building block, and won't be valued as it should as it's designed to be a guard rail that is brushed under the rug.
I use C++ when writing bindings and native addons for managed languages, on my graphics programming hobby code, do agree with the criticism, which I note even the language's creator is opposed to.
They will be another modules disaster, being pushed into the standard without proper implementation, and many open questions for several deployment scenarios.
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.
If you had any experience on the topic you'd be quite aware of the issues caused by tools scrambling to support the feature. For example, GCC only claimed official support for modules a few months ago with the release of GCC 15. Even Ubuntu 2026 LTS broke modules support.
If you want to learn about the topic, I recommend you start by getting acquainted with CMake and its state of modules support.
It goes to show how your opinions contrast with your knowhow.
> Contracts are much worse
Nonsense. Worst case they are annotations you can safely ignore. The fact you try to portray annotations used to aid static analysis as "much worse" than a complete revolution of how build systems manage dependencies and binaries just goes to show how detached from reality your comments are.
Neither am I. I'm stressing that your vocal and enthusiastic criticism is uninformed and detached from reality. You're commenting on things you are clearly uninformed or misinformed, and presenting your reddit credentials as appeal to authority is a clear demonstration of what supports that opinion.
You are free to be vocal and criticize things, but the depth of your understanding and discourse is also a factor.
I think unfair criticism happens because of decades of standard committee clinging to power, not listening to actual community feedback and proposals, and just straight on systematically favoring its own research toys WG instead.
So yes, the more time goes on, the more anything coming out of the SC receives biased negative feedback.
Contracts received a high volume of unfair criticism from unwitting observers, some of which don't even use C++ at all. I think this will be one of those features that is of critical importance and a fundamental building block, and won't be valued as it should as it's designed to be a guard rail that is brushed under the rug.
I use C++ when writing bindings and native addons for managed languages, on my graphics programming hobby code, do agree with the criticism, which I note even the language's creator is opposed to.
They will be another modules disaster, being pushed into the standard without proper implementation, and many open questions for several deployment scenarios.
> 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.
> That shows how much you know modules, what is your experience with header units?
More than enough to understand quite well that at this point it is a tooling issue.
https://gitlab.kitware.com/cmake/cmake/-/work_items/25293
If you had any experience on the topic you'd be quite aware of the issues caused by tools scrambling to support the feature. For example, GCC only claimed official support for modules a few months ago with the release of GCC 15. Even Ubuntu 2026 LTS broke modules support.
If you want to learn about the topic, I recommend you start by getting acquainted with CMake and its state of modules support.
https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules....
It goes to show how your opinions contrast with your knowhow.
> Contracts are much worse
Nonsense. Worst case they are annotations you can safely ignore. The fact you try to portray annotations used to aid static analysis as "much worse" than a complete revolution of how build systems manage dependencies and binaries just goes to show how detached from reality your comments are.
My github and /r/cpp/ presence is a proof of how much experience I have in practice.
As for you trying to educate me, whatever dude.
You would be better spending your time reading the mailing papers that point out the design flaws.
In case you want to learn about the topic, that is.
> My github and /r/cpp/ presence is a proof of how much experience I have in practice.
Oh a redditor. I'm sorry, I didn't knew I was talking to an expert.
> As for you trying to educate me, whatever dude.
Lost cause?
> You would be better spending your time reading the mailing papers that point out the design flaws.
Nitpicking areas of improvement does not reflect critical issues with the feature. This is not reddit.
I am not the one trolling around here.
> I am not the one trolling around here.
Neither am I. I'm stressing that your vocal and enthusiastic criticism is uninformed and detached from reality. You're commenting on things you are clearly uninformed or misinformed, and presenting your reddit credentials as appeal to authority is a clear demonstration of what supports that opinion.
You are free to be vocal and criticize things, but the depth of your understanding and discourse is also a factor.
I think unfair criticism happens because of decades of standard committee clinging to power, not listening to actual community feedback and proposals, and just straight on systematically favoring its own research toys WG instead.
So yes, the more time goes on, the more anything coming out of the SC receives biased negative feedback.