Reflection for C++26

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it.

Looking at the examples (https://isocpp.org/files/papers/P2996R4.html#examples) what really stands out is the direct integration of type-syntax into the language. It fits in with a certain token-substitution way that connects back to templates. It also replaces some of the uglier operators (typeof?).

I hope it goes int! During the language's stagnation I left for a while, perhaps it'll be competitive again soon.

By ”stagnation” do you mean “not getting new features”?

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy.

So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

> There are still too many half-baked ideas that turn out to be mistakes afterwards (...)

Care to point an example?

Some examples on top of my mind:

- export templates is the canonical one.

- Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal.

- Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun.

- Coroutines are overly complex and still incomplete but I still have hope.

- Modules feel DOA so far.

- Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property.

edit: overall I'm happy with the evolution of the language, but the standardization process has flaws