C++ does not win any prizes for being the most aesthetically pleasing programming language but the new syntax around reflection is pretty ugly even by those standards.
This syntax is pretty weird even by C++ standards, and it's certainly the worst way to do reflection I've personally seen. But I guess it's good that C++ is finally getting some kind of reflection. Only a few decades late to the party but hey they got there in the end.
Really as C++ grows and evolves, I feel more and more that I'd rather use plain C than wrangle with all of the bizzarro choices C++ has made. C++ is more and more often just the wrong choice of language for anything I want to do. If I need compile-time reflection, I'll use a C# program to generate C code.
> use a C# program to generate C code
These seem at odds.
(Scala is another example of such a language.)
Equally, Perl explicitly tried a number of syntactic ways to do something; some stuck as good ideas, some were demonstrated to be... less good. I think it was important to explore and show that a particular approach has serious downsides in practice, but it's not necessary to stick to in once better alternatives are available.
> I do not have access yet to a true C++26 compiler. When C++26 arrive, we will have features such as ‘template for’ which are like ‘for’ loops, but for template metaprogramming. Meanwhile, I use a somewhat obscure ‘expand’ syntax.
In particular, regarding the most cryptic line:
[:expand(nonstatic_data_members_of(^^T, ctx)):] >> [&]<auto member>{
In fact, at least from what I know, `expand()` and this fancy use of `>>` aren't actually part of the standard (the standard proposal uses them as an temporary example in case other features didn't get in). The equivalent (I think) line with the C++26 approved features would be a bit more friendly:
template for (constexpr auto member : nonstatic_data_members_of(^^T, ctx)) {
So while it's still not the prettiest thing in the world and knowing C++, it surely will produce some eldritch metaprogramming abominations, the author's examples made it look slightly uglier than it actually is.
This isn't reflection though, it's just textual code generation. In a way, it has the same problem's Rust's macros have (and indeed I'd love to have this kind of reflection in Rust). As an example, if you're implementing some kind of automated serialization, given an input struct with several fields, how can you even just find out its size? Or at what offset each field lives? Or if the field can be naively memcpy'd? You can hardcode the values if you do lots of assumptions and restrictions, or you can re-implement the logic the compilers already also do - but IMO it does feel the cleanest to just ask the compiler at compile time, which is exactly what C++ reflection proposal does.
That aside, it isn't that easy to switch languages because C++ is more expressive in a systems context in important ways. Porting existing modern systems C++ to e.g. Rust makes this pretty obvious. (I think porting to Zig would likely be a bit easier but I've never actually tried.)
I'm just using all of this on embedded platforms without issues - and can't wait to use reflection there either, it'll be ultra useful for ESP32 and Teensy projects we're working on
npalli•3h ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29...
PessimalDecimal•3h ago
techjamie•2h ago
That's on brand for C++ in general. It works well, but it's ugly as sin while doing it.
bestouff•1h ago
grg0•13m ago
layer8•2h ago