Discussion

rustyhancock: I look forwards to getting to make use of this in 2040!Proper reflection is exciting.

LatencyKills: This is awesome. I've was a dev on the C++ team at MS in the 90s and was sure that RTTI was the closest the language would ever get to having a true reflection system.

mohamedkoubaa: Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption

zarzavat: The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging.It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.

affenape: Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.

luka598: Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

forrestthewoods: No. Modules are a failed idea. Really really hard for me to see them becoming mainstream at this point.

Xraider72: No idea if modules themselves are failed or no, but if c++ wants to keep fighting for developer mindshare, it must make something resembling modules work and figure out package management.yes you have CPM, vcpkg and conan, but those are not really standard and there is friction involved in getting it work.

suby: I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified.Here's a quote from Bjarne,> So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much harder problem. This is part of the standard proposal. Do we vote against the standard because there is a feature we think is bad? Because I think this one is bad. And that is a much harder problem. People vote yes because they think: "Oh we are getting a lot of good things out of this.", and they are right. We are also getting a lot of complexity and a lot of bad things. And this proposal, in my opinion is bloated committee design and also incomplete.

addaon: I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of that — see e.g. Ada Spark.

delduca: Sadly, transparent hash strings for unordered_map are out.

groundzeros2015: I didn’t think header only was that bad - now we have a nightmare of incompatible standards and compilers.

bluGill: The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance.Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.

dislikedopinion: Might be the case that Ada folks successfully got a bad version of contracts not amenable for compile-time checking into C++, to undermine the competition. Time might tell.

porise: I don't care until they stop pretending Unicode doesn't exist.

StilesCrisis: Much like contracts--yes, C++ needs something modules-like, but the actual design as standardized is not usable.Once big companies like Google started pulling out of the committee, they lost their connection to reality and now they're standardizing things that either can't be implemented or no one wants as specced.

ho_schi: I’m still surprised how people ignore Meson:https://mesonbuild.com/And Mesons awesome dependency handling:https://mesonbuild.com/Dependencies.htmlhttps://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapd...After reading about GNU Autotools (help!) and suffering ever awful thing Java created I wondered if C/C++ could do better. They do. For years :)

hrmtst93837: "Failed idea" gives modules too much credit. Outside old codebases, almost no one outside C++ diehards have the patience for the build and tooling circuss they create, and if you need fast iteration plus sane integration with existing deps, modules are like trading your shoes for roller skates in a gravel lot. Adopting them now feels like volunteering to do tax forms in assembbly.

mgaunard: It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source.C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous.There are of course good ways of building C++, but those are the exception rather than the standard.

NetMageSCW: I would suggest importing binaries and metadata is going to be faster than compiling all the source for that.