The C++ committee held a meeting the week of the 10 February, in the lovely little village of Hagenberg. Far away from the civilization, we were hard at work on C++26. It was the last meeting to send new features to the wording groups. At the next meeting, C++26 will be complete and send to national bodies for comments.

As both my day job and my role as a Clang maintainer require me to pay very close attention to the language, I spent no more than a few minutes in library evolution.

Library features

I wish I could find the time to follow what’s happening to sender receiver, but alas, I’m spread way too thin. I have some concerns that we might ship C++26 without a system executor, which frankly would be cause to vote the whole thing down. It should be a requirement that standard library components are relatively self contained and usable out of the box.

In general, I feel Sender and Receivers could have used a longer runway, and I struggle to get a good picture of how mature everything really is. We have a year to figure out the kinks.

For some reason, LEWG felt that Concurrent Queues were ready for C++26, despite a lot of changes in the past few months, and a lack of experience with sender receivers.

The most exciting thing that seems to have happen in LEWG this week is that we forwarded std::optional<T&>, which as a very strong shot at C++26. Should have that taken 8 years and multiple authors? Probably not, but are we are at last!

Parallel ranges algorithms are also pretty neat. The just add an execution policy to the range algorithms, which makes range algorithms usable in all cases.

Reflection

I should be excited about Reflection. It’s something users have asked for a very long time. And part of it will be very useful, for sure. You wanted to know the names of your enumerators, and you will get them. We also, finally, landed on a sane policy in regard to access control. Thanks Dan!

But Reflection still runs the risk to turn code into unmaintainable token source. From reflecting on parameter names (which have never been part of the API), to attributes (in C++29, if at all) - which are actual token soup, to-very-hard-to-reason-about, half-baked, not-generally-useful generative metaprogramming features that seem to only exist so that we have “something” in C++26… I’m afraid reflection will be pretty disruptive in the ecosystem and very hard to use and maintain.

Some features, which I think are pretty critical to the usability of reflection, notably constexpr format, non-transient allocations and better NTTPs missed the boat.

This has been paliated by short terms hacks such as define_static_string, but these are short term solutions that will just become cruft, almost immediately.

The good news is that, we finally sent expansion statements back to core for C++26, another feature that I find necessary to do anything useful with reflection.

Fortunatelly, it will take a while for compilers to implement reflection. There are after all, hundreds of built-in to support and pretty fundamental changes are necessary to support side effects at constexpr. With luck, we migt land on a well rounded set of features sometimes in the next couple of years.

And maybe a few people will be able to use some of these features productively!