C++ people are great at making problems for themselves and then solving them to no end.

This does not look like a productive way to get things done.

C arrays are better than this mess. All the problems caused by the intervening generic programming abstraction machinery disappear.

The nice thing about C++ is that if you want to use plain old C arrays, you can. And there will be no extra overhead over plain C.

You will lose many nice features like fancy strings and easy array resizing (which may or may not be acceptable to you), but you don’t have to pay for it if you don’t use it. (Mostly)

This does seem pretty complicated. And I doubt I will ever use it. But for some the trade off is worth it, and they get to make the choice.

Didn't know you could use C arrays to get static compile time reflection, guess C was really ahead of its time!

What language do you consider to be productive, in comparison?

Rather than engage in an unrelated language-war flame bait, why not actually discuss this particular issue with C++? Yes having a language built around zero cost abstractions for low level programming is a must, but how does that end up justifying this wild complexity around making constexpr more powerful?

In the real world I would think trying to do any of the things discussed in this article should be an automatic commit rejection on any project.

This particular issue is a niche corner case of C++26 reflection, which -- like reflection in other languages -- is a massively useful feature.

In the real world, failing to understand what you're reading and eagerly generalising to the entire language should be an automatic hiring rejection in any team.

C++ critics are great at analyzing niche corner cases of the language and generalising those to the entirety of its feature set.

This does not look like a productive way to get things done.

This is so on-brand for C++, whether that is a blessing or curse is left up to the reader.

To be clear we are — in the service of speed — trying to bake data into compiled program output binaries, which is ostensibly faster because code-pages in memory when executed by CPU as instructions already have it?

No you are baking data into the compiled program so that you can perform compile time operations on that data. These compile time operations are most often used to guard against erroneous runtime behaviors.

If all you want to do is bake data into a compiled program, there is the #embed feature added to C++26.

> Think of constexpr evaluation as taking place "in the compiler’s imagination."

This is a great line.

constexpr and std::execution seem like neat ideas, maybe I'll give them a shot if I build an AI harness around the compiler so it doesn't make me feel like a hopeless idiot for trying new things.