6 ms·

Discover C++26's compile-time reflection

54 points by jandeboevrie 1y ago

npalli 1y ago
Also, it is worthwhile reading the standard proposal paper for lot of examples of how this might be used in the future. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r12.html#examples https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29...
- PessimalDecimal 1y ago
  Thanks for this link. Between it and the main article, I have a much better sense for how compile time reflection will actually be useful. The syntax is bad enough to make my eyes bleed, but at least they'll bleed for a good reason I hope.
  - techjamie 1y ago
    > The syntax is bad enough to make my eyes bleed That's on brand for C++ in general. It works well, but it's ugly as sin while doing it.
    - bestouff 1y ago
      I don't agree with you. Yes syntax is often awful but no it doesn't work that well. It's a minefield of Undefined Behavior.
      - pjmlp 1y ago
        While true, just like everyone on Rust land rarely thinks about configuring their projects without clippy, C and C++ developers should learn static analysers for C and eventually C++ exist since 1979. It doesn't fix everything, yet it fixes more than those that don't use them at all. I have been using such tools since mid-1990's when coding in either C or C++, and sadly it is still a discussion point regarding adoption.
    - grg0 1y ago
      I am happy^^ that ^^ is our quote character. ^^
- layer8 1y ago
  The rationale in section 2.2 for the single std::meta::info type is interesting. While having a single “dynamic” type is fine insofar as any type error would occur at compile time anyway, I wonder if there wouldn’t be a way to maintain future backwards compatibility for finer-grained meta types, as long as the language elements they reflect remain backwards-compatible in the language as well. From first principles, one would think that it should be possible for the backwards compatibility of the reflection system to mirror the backwards compatibility of the reflected language. I’d be interested in the underlying reasons for why this isn’t the case, if any.
jandrewrogers 1y ago
I am looking forward to compile-time reflection, C++ has unusually strong metaprogramming capabilities among systems languages and this will significantly bolster that. 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.
- paulddraper 1y ago
  Correct on all counts
- rickstanley 1y ago
  Yeah. I was wondering if it would be feasible to have a superset language for C++, much like what TypeScript is for JavaScript. But I guess there's always the risk of bike-shedding hell.
mystified5016 1y ago
Wow. That is... certainly some syntax. It reminds me of Perl. 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.
- PessimalDecimal 1y ago
  > compile-time reflection > use a C# program to generate C code These seem at odds.
  - jcelerier 1y ago
    you call the C# program that generates the code as part of your build system
    - PessimalDecimal 1y ago
      I get it. That's code generation. But it's not compile time reflection.
- nine_k 1y ago
  The comparison with Perl is apt, to my mind. Both Perl and C++ were early to their space, experimenting with concepts that were weird at the time, trying many approaches we now find ugly, and serving as examples of both successes and failures for the much better languages that came after them. The difference is that Perl5 stopped evolving some time ago, while C++ continues the same tendency unabashed. (Scala is another example of such a language.)
  - stathibus 1y ago
    Are you suggesting that reflection is a new fancy thing and c++ is paving the way?
MoonGhost 1y ago
How about thin C++ wrapper? The language with the same features, but more human friendly. It should be easily directly translated to C++. Preferably both ways.
- nine_k 1y ago
  C++'s semantics are also broken in interesting ways: UB, implicit conversions, arrays, exceptions, exceptions from destructors, etc. Papering over them won't help all that much. It's more efficient to just swallow the bullet and switch to Rust (or maybe Zig).
  - jandrewrogers 1y ago
    Many of these inadvisable semantics are fixable in practice, they are just a default that requires additional effort to minimize or eliminate. 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.)
  - theICEBeardk 1y ago
    Yeah no switching a group of developers over to some new language is not more efficient. It is a lot of work. And on top of that you will need to add time to either wrap your existing code base or rewrite it with developers who are new to the language they are using. You will have folks who like that and can do it, but you will also have a lot who would have a much harder time with that. Most corporations would legitimately ask what is switching the language gaining us and is it worth it. Now the conclusion might be that it is worth it, but it is equally possible that they decide against it. Never underestimate inertia.
- layer8 1y ago
  There are languages like D and Carbon that attempt this. But there are too many existing large C++ code bases to not continue evolving C++ itself as well.
jasonthorsness 1y ago
Seems like maybe it will be a challenge to use, but like a lot of template stuff the complexity gets buried in the library. The language gets a lot of ridicule but I like the no-compromise push to help programmers eliminate unnecessary runtime work in their programs.
- 112233 1y ago
  The corollary of that is that most new c++ features get designed with the explicit intent of getting burried in std library implementation (with coroutines being excellent example). Then, developer is presented with a nice, easy to use library interface, that violently explodes all the obscure implementation details in their face on first error. Modern C++ is made, I feel, primarily to make STL implementation less embarrassing.
112233 1y ago
Oh noes, the binding of internal compiler state to STL will become even more severe with this. It started slowly. You needed exact magic std::initializer_list definition in your headers to match the code generated by the compiler, or the program would crash. RTTI (that was of little use to programs that tried to avoid standard library) Now there are coroutines and this thing. I feel like it is bye-bye to the completely non-standard compliant practice of using C++ without all the standard library. Where should embedded c++ projects go now that they are not welcome anymore?
- jcelerier 1y ago
  > Where should embedded c++ projects go now that they are not welcome anymore? 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
- dodomodo 1y ago
  It's not that hard to just copy the relevant part from the standard library of your platform
- adrian17 1y ago
  The std::meta stuff are only ever running at compile time, so I don't think this would actually interfere much?
  - 112233 1y ago
    now that a lot of std:: is constexpr, who knows how much of it will get pulled into compile time by std::meta stuff (I do not. I am asking). I know of no way of using different std libraries, one for compile time and one for target. Meaning, using this c++ variant without std library shipped with the compiler just got even impossiblier.
- TuxSH 1y ago
  About everything in std::initializer_list is noexcept, and builtin wrappers (type traits, bit_cast etc etc.) are 0-cost. You shouldn't try to avoid all of the stdlib, but rather vet what you use from it. Furthermore, stuff like LTO or -ffunction-sections -fdata-sections (+ --gc-section when linking) gets rid of unused symbols, as long as your toolchain provider compiles the C stdlib and C++ stdlib with these > coroutines Almost everything is customizable by user (including class-scoped operator new), is it not? > Where should embedded c++ projects go now that they are not welcome anymore? C++ is still very much suitable for embedded, and while I disagree with most of your post I agree that: 1) there should be a linker flag to wrap all std:: exceptions instead of using -Wl,-wrap for each individual exception when needed and 2) that embedded feels like a second-class citizen sometimes ("deprecating volatile" (reverted), #embed missing C++23 etc)
izger 1y ago
C++ became more and more cryptic. Make C++ code creation programmable (templating) by basic c++ syntax at compile time. Make this a part of the standard library.

54 points by jandeboevrie 1y ago

Also, it is worthwhile reading the standard proposal paper for lot of examples of how this might be used in the future. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r12.html#examples https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29...

PessimalDecimal 1y ago
Thanks for this link. Between it and the main article, I have a much better sense for how compile time reflection will actually be useful. The syntax is bad enough to make my eyes bleed, but at least they'll bleed for a good reason I hope.
- techjamie 1y ago
  > The syntax is bad enough to make my eyes bleed That's on brand for C++ in general. It works well, but it's ugly as sin while doing it.
  - bestouff 1y ago
    I don't agree with you. Yes syntax is often awful but no it doesn't work that well. It's a minefield of Undefined Behavior.
    - pjmlp 1y ago
      While true, just like everyone on Rust land rarely thinks about configuring their projects without clippy, C and C++ developers should learn static analysers for C and eventually C++ exist since 1979. It doesn't fix everything, yet it fixes more than those that don't use them at all. I have been using such tools since mid-1990's when coding in either C or C++, and sadly it is still a discussion point regarding adoption.
  - grg0 1y ago
    I am happy^^ that ^^ is our quote character. ^^
layer8 1y ago
The rationale in section 2.2 for the single std::meta::info type is interesting. While having a single “dynamic” type is fine insofar as any type error would occur at compile time anyway, I wonder if there wouldn’t be a way to maintain future backwards compatibility for finer-grained meta types, as long as the language elements they reflect remain backwards-compatible in the language as well. From first principles, one would think that it should be possible for the backwards compatibility of the reflection system to mirror the backwards compatibility of the reflected language. I’d be interested in the underlying reasons for why this isn’t the case, if any.

jandrewrogers 1y ago

I am looking forward to compile-time reflection, C++ has unusually strong metaprogramming capabilities among systems languages and this will significantly bolster that. 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.

paulddraper 1y ago
Correct on all counts
rickstanley 1y ago
Yeah. I was wondering if it would be feasible to have a superset language for C++, much like what TypeScript is for JavaScript. But I guess there's always the risk of bike-shedding hell.

mystified5016 1y ago

Wow. That is... certainly some syntax. It reminds me of Perl. 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.

PessimalDecimal 1y ago
> compile-time reflection > use a C# program to generate C code These seem at odds.
- jcelerier 1y ago
  you call the C# program that generates the code as part of your build system
  - PessimalDecimal 1y ago
    I get it. That's code generation. But it's not compile time reflection.
nine_k 1y ago
The comparison with Perl is apt, to my mind. Both Perl and C++ were early to their space, experimenting with concepts that were weird at the time, trying many approaches we now find ugly, and serving as examples of both successes and failures for the much better languages that came after them. The difference is that Perl5 stopped evolving some time ago, while C++ continues the same tendency unabashed. (Scala is another example of such a language.)
- stathibus 1y ago
  Are you suggesting that reflection is a new fancy thing and c++ is paving the way?

MoonGhost 1y ago

How about thin C++ wrapper? The language with the same features, but more human friendly. It should be easily directly translated to C++. Preferably both ways.

nine_k 1y ago
C++'s semantics are also broken in interesting ways: UB, implicit conversions, arrays, exceptions, exceptions from destructors, etc. Papering over them won't help all that much. It's more efficient to just swallow the bullet and switch to Rust (or maybe Zig).
- jandrewrogers 1y ago
  Many of these inadvisable semantics are fixable in practice, they are just a default that requires additional effort to minimize or eliminate. 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.)
- theICEBeardk 1y ago
  Yeah no switching a group of developers over to some new language is not more efficient. It is a lot of work. And on top of that you will need to add time to either wrap your existing code base or rewrite it with developers who are new to the language they are using. You will have folks who like that and can do it, but you will also have a lot who would have a much harder time with that. Most corporations would legitimately ask what is switching the language gaining us and is it worth it. Now the conclusion might be that it is worth it, but it is equally possible that they decide against it. Never underestimate inertia.
layer8 1y ago
There are languages like D and Carbon that attempt this. But there are too many existing large C++ code bases to not continue evolving C++ itself as well.

jasonthorsness 1y ago

Seems like maybe it will be a challenge to use, but like a lot of template stuff the complexity gets buried in the library. The language gets a lot of ridicule but I like the no-compromise push to help programmers eliminate unnecessary runtime work in their programs.

112233 1y ago
The corollary of that is that most new c++ features get designed with the explicit intent of getting burried in std library implementation (with coroutines being excellent example). Then, developer is presented with a nice, easy to use library interface, that violently explodes all the obscure implementation details in their face on first error. Modern C++ is made, I feel, primarily to make STL implementation less embarrassing.

112233 1y ago

Oh noes, the binding of internal compiler state to STL will become even more severe with this. It started slowly. You needed exact magic std::initializer_list definition in your headers to match the code generated by the compiler, or the program would crash. RTTI (that was of little use to programs that tried to avoid standard library) Now there are coroutines and this thing. I feel like it is bye-bye to the completely non-standard compliant practice of using C++ without all the standard library. Where should embedded c++ projects go now that they are not welcome anymore?

jcelerier 1y ago
> Where should embedded c++ projects go now that they are not welcome anymore? 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
dodomodo 1y ago
It's not that hard to just copy the relevant part from the standard library of your platform
adrian17 1y ago
The std::meta stuff are only ever running at compile time, so I don't think this would actually interfere much?
- 112233 1y ago
  now that a lot of std:: is constexpr, who knows how much of it will get pulled into compile time by std::meta stuff (I do not. I am asking). I know of no way of using different std libraries, one for compile time and one for target. Meaning, using this c++ variant without std library shipped with the compiler just got even impossiblier.
TuxSH 1y ago
About everything in std::initializer_list is noexcept, and builtin wrappers (type traits, bit_cast etc etc.) are 0-cost. You shouldn't try to avoid all of the stdlib, but rather vet what you use from it. Furthermore, stuff like LTO or -ffunction-sections -fdata-sections (+ --gc-section when linking) gets rid of unused symbols, as long as your toolchain provider compiles the C stdlib and C++ stdlib with these > coroutines Almost everything is customizable by user (including class-scoped operator new), is it not? > Where should embedded c++ projects go now that they are not welcome anymore? C++ is still very much suitable for embedded, and while I disagree with most of your post I agree that: 1) there should be a linker flag to wrap all std:: exceptions instead of using -Wl,-wrap for each individual exception when needed and 2) that embedded feels like a second-class citizen sometimes ("deprecating volatile" (reverted), #embed missing C++23 etc)

izger 1y ago

C++ became more and more cryptic. Make C++ code creation programmable (templating) by basic c++ syntax at compile time. Make this a part of the standard library.