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.

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.

> 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?

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

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.

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

std::execution is very interesting, but will be difficult to get started with, as cautioned by Sutter. This HPC Wire article demonstrates how to use standard C++ to benefit from asynchronously parallel computation on both CUDA and MPI:

https://www.hpcwire.com/2022/12/05/new-c-sender-library-enab...

Overlapping communication and computation has been a common technique for decades in high-performance computing to "hide latency", which leads to better scaling. Now standard C++ can be used to express parallel algorithms without tying to a specific scheduler.

I switched from C++ to Java/Python 20 years ago. I never really fit in, I just dont understand when people talk about the complicated frameworks to avoid multithreading/mutexes etc when basic C++ multi threading is much simpler than rxjava or async/await or whatever is flavor of the month.

But C++ projects are usually really boring. I want to go back but glad I left. Has anyone found a place where C++ style programming is in fashion but isn't quite C++? I hope that makes sense.

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.

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

If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things:

1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done).

2. Uniform Function Call Syntax! That is, make the syntax `obj.f(arg)` mean simply `f(obj, arg)` . That would make my life much easier, both as a user of classes and as their author. In my library authoring work particularly. And while we're at it, let us us a class' name as a namespace for static methods, so that Obj::f the static method is simply the method f in namespace Obj.

3. Get compiler makers to have an ABI break, so that we can do things like passing wrapped values in registers rather than going through memory. See: https://stackoverflow.com/q/58339165/1593077

4. Get rid of the current allocators in the standard library, which are type-specific (ridiculous) and return pointers rather than regions of memory. And speaking of memory regions (i.e. with address and size but no element type) - that should be standardized too.

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.

I am curious what is their strategy to get language to the stage where the US government will make it cosher for new projects

"Japanese soldier who kept fighting 29 years after World War 2"

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.

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."