C++26 is done ISO C++ standards meeting, Trip Report

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.

Contracts feel like the right direction but the wrong execution timeline. The Ada/SPARK model shows how powerful contracts become when they feed into static verification — but that took decades of iteration on a language with far cleaner semantics. Bolting that onto C++ where UB is load-bearing infrastructure is a different beast entirely. The real risk isn't complexity for complexity's sake — it's that a "minimum viable" contracts spec gets locked in, and then the things that would actually make it useful for proof assistants become impossible to retrofit because they'd break the v1 semantics. Bjarne's concern about "incomplete" is more worrying to me than "bloated."

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost:

    int x [[indeterminate]];
    std::cin >> x;

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.

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

> Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release.

How far is Clang on reflection and contracts?

I am actually excited for post and pre conditions. I think they are an underused feature in most languages.

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

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.

As long as programmers still have to deal with header files, all of this is lipstick on a pig.

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

Sadly, transparent hash strings for unordered_map are out.

I look forwards to getting to make use of this in 2040!

Proper reflection is exciting.

Seeing that pic at the top of the article, and reflecting on my own experiences with rust: It is wild just how male-centric systems programming languages are. I'm from a career backround that's traditionally male-dominated (military aviation), but the balance is far more skewed among C, C++ and Rust developers.