C++26 is done ISO C++ standards meeting, Trip Report
herbsutter.com

・

55 points

・

pjmlp

・

2 hours ago

20 comments

suby ・ 20 minutes ago

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.

  • raincole ・ a minute ago

    I mean... it's C++. The complexity budget is like the US government's debt ceiling.

  • addaon ・ 7 minutes ago

    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.

    • bluGill ・ 3 minutes ago

      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.

    • StilesCrisis ・ 5 minutes ago

      Right, I think the tension here is that we would like contracts to exist in the language, but the current design isn't what it needs to be, and once it's standardized, it's extremely hard to fix.

LatencyKills ・ an hour ago

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 ・ an hour ago

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

  • zarzavat ・ 28 minutes ago

    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.

    • mgaunard ・ 5 minutes ago

      In my experience, no one does build systems right; Cargo included.

      The standard was initially meant to standardize existing practice. There is no good existing practice. Very large institutions depending heavily on C++ systematically fail to manage the build properly despite large amounts of third party licenses and dedicated build teams.

      With AI, how you build and integrate together fragmented code bases is even more important, but someone has yet to design a real industry-wide solution.

    • luka598 ・ 17 minutes ago

      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.

    • groundzeros2015 ・ 10 minutes ago

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

  • jjmarr ・ 23 minutes ago

    No, because most major compilers don't support header units, much less standard library header units from C++26.

    What'll spur adoption is cmake adopting Clang's two-step compilation model that increases performance.

    At that point every project will migrate overnight for the huge build time impact since it'll avoid redundant preprocessing. Right now, the loss of parallelism ruins adoption too much.

  • forrestthewoods ・ 35 minutes ago

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

    • m-schuetz ・ 21 minutes ago

      The idea is great, the execution is terrible. In JS, modules were instantly popular because they were easy to use, added a lot of benefit, and support in browsers and the ecoysystem was fairly good after a couple of years. In C++, support is still bad, 6 years after they were introduced.

    • Xraider72 ・ 19 minutes ago

      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.

delduca ・ 10 minutes ago

Sadly, transparent hash strings for unordered_map are out.

levodelellis ・ 25 minutes ago

Great. C++20 has been my favorite and I was wasn't sure what the standards says since it's been a while. I'll be reading the C++26 standard soon

affenape ・ 33 minutes ago

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.