C++26: Standard Library Hardening
sandordargo.com
sandordargo.com
So yes, the more time goes on, the more anything coming out of the SC receives biased negative feedback.
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.
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.
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.
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.
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.
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.
Some of my code is public, yours?
Coming up on HN, talking down people, yeah right, what an expert that we have here.