5 ms·

I look at C++ code like this and feel like it's from a different planet. These are keywords and approaches I just never use myself. Templates ocassionally, but

I look at C++ code like this and feel like it's from a different planet. These are keywords and approaches I just never use myself. Templates ocassionally, but auto templates? std::meta? Whatever [:Member:] is? nonstatic_data_members_of? std::is_void_v? Plus the lambdas make this syntax even worse. It feels like I'm looking at a conlang instead of C++. Not hating the author, I'm sure they know their stuff and this is useful to someone. Just looking at this from the perspective of an ordinary C++ programmer, it looks very alien.

jryan49 2y ago
Yeah look at this eye watering line: using ret_t = first_non_void<decltype(fnc.template operator()<Elts>())...>;
- dataflow 2y ago
  Of all the C++ complexities that's not the one I would complain about. All it's doing is getting the first non-void declared return type of the operator() invocations, each specialized with the Elts template parameter. It reads basically as you'd write it in English. There's much more eye-watering stuff out there!
  - deleted 2y ago
    [deleted]
- greatgib 2y ago
  For me the following one is insane: constexpr void operator>>(F fnc) const { (fnc.template operator()<Elts>(), ...); }
  - gpderetta 2y ago
    I think that the choice of overloading operator>> is from the blog author though, it is not from the introspection proposal.
vinkelhake 2y ago
You're looking at constructs mostly related to C++26 reflection. It's very new, so that might be why it looks like it's from a different planet. They necessarily had to invent some new syntax for it. I think C++26's reflection is likely to be one of the most important changes to the language in a very long time.
- tsimionescu 2y ago
  Did they have to invent new syntax for it? All other languages that have reflection have regular function calls for it. Why do ^^X instead of reflect(X)?
  - gpderetta 2y ago
    Not very many languages have compile time reflection. This is more like macros and syntax splicing. Still a reflect keyword could have worked. Some argued that in reflection heavy code you would reflect a lot and the keyword would be a lot of noise. I don't know if the reflection papers have been voted in already (I forgot how to check), so the syntax might still be up for debate.
  - edflsafoiewq 2y ago
    According to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r10.html#syntax-discussion https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29... > The original TS landed on reflexpr(...) as the syntax to reflect source constructs and [P1240R0] adopted that syntax as well. As more examples were discussed, it became clear that that syntax was both (a) too “heavy” and (b) insufficiently distinct from a function call. SG7 eventually agreed upon the prefix ^ operator. The “upward arrow” interpretation of the caret matches the “lift” or “raise” verbs that are sometimes used to describe the reflection operation in other contexts.
thechao 2y ago
I tried pitching "generalized overloads" to Bjarne on a few occasions: `operator .` is highly problematic (you can read about it); but a number of the other `operator`s seem to be ok: `;`, `?:`, `if`, `for`, `while`, `switch-case`. Where things get challenging are: `goto-label` (just... mechanically). And, finally, do we want to overload aggregate & enumeration declaration? `typedef` declaration (this gets into name unification which is really awkward in templated contexts); function definitions, etc.). My argument was "leave that for C++14". For 90% of the code I was looking at the statement-level `operator`s solved the problems I had: it promoted the body of the functions into plain-old-template metaprogramming. Templated return types (a la Veldhuizen) converted function definitions into first class types that let me operate on functions, just like we've always done.
- lpapez 2y ago
  Thankfully I no longer work with C++, but such proposals were my main problem with the language. I had the impression that the vast majority of us regular users just wanted quality of life improvements: better error messages, networking library, a standard package manager etc. Literally most of what C++ code styles are concerned with is about picking what features are banned in that particular style. But instead of doing something pratical, the commitee always went with the route of adding increasingly niche features citing that useful things are "out of scope" or "implementation defined" or "userspace". So what you get is incompatible ecosystems and cultures for an extremely complicated language. Very happy working with Go presently, where exactly the opposite approach is being taken by maintainers. Eg: There was huge pushback regarding generics introduction (a genuinely useful language feature IMO), but they introduced very good vulnerability scanning (govulncheck) without me even hearing about it being under development.
  - gpderetta 2y ago
    People want better error messages, networking, a package manager, etc. But they also want compile time reflection. Sometimes it is even the same people!
    - 2y ago
Aardwolf 2y ago
To me it's the ^^, like in ``` void print_members(T const& obj) { [:expand(nonstatic_data_members_of(^^T)):] ``` What is this ^^?
- edflsafoiewq 2y ago
  It's the reflection operator. Reflection is supposed to be part of the yet-unreleased C++26, so it's not surprising you don't know it.
- pjmlp 2y ago
  It was supposed to be only one ^ however it conflicts with Objective-C blocks, so they ended up settling on two ^^. However many of us would have prefered reflect(T), but again many on WG21 seem to use notepad for programming and don't like to type. It means the reflection data of the type.
  - misnome 2y ago
    > however it conflicts with Objective-C blocks, so they ended up settling on two ^^. Which… were never added to C++, right? What a mess.
    - pjmlp 2y ago
      No, they are Objective-C only, and since there is this thing called Objective-C++, where one can combine Objective-C and C++ on the same source file, an alternative had to be chosen. Personally I would rather have reflect.
  - saelthavron 2y ago
    > it conflicts with Objective-C blocks Why does that matter? > many of us would have prefered reflect(T), but again many on WG21 seem to use notepad for programming and don't like to type. I don't know about anyone else, but I find reflect(T) much easier to type than ^^T. I have a high error rate on hitting 6. Not only that I have to move my hand from the home row to hit it.
Wumpnot 2y ago
It is using c++ 26 features, so of course it looks slightly alien, nobody uses it yet.

jryan49 2y ago

Yeah look at this eye watering line: using ret_t = first_non_void<decltype(fnc.template operator()<Elts>())...>;

dataflow 2y ago
Of all the C++ complexities that's not the one I would complain about. All it's doing is getting the first non-void declared return type of the operator() invocations, each specialized with the Elts template parameter. It reads basically as you'd write it in English. There's much more eye-watering stuff out there!
- deleted 2y ago
  [deleted]
greatgib 2y ago
For me the following one is insane: constexpr void operator>>(F fnc) const { (fnc.template operator()<Elts>(), ...); }
- gpderetta 2y ago
  I think that the choice of overloading operator>> is from the blog author though, it is not from the introspection proposal.

vinkelhake 2y ago

You're looking at constructs mostly related to C++26 reflection. It's very new, so that might be why it looks like it's from a different planet. They necessarily had to invent some new syntax for it. I think C++26's reflection is likely to be one of the most important changes to the language in a very long time.

tsimionescu 2y ago
Did they have to invent new syntax for it? All other languages that have reflection have regular function calls for it. Why do ^^X instead of reflect(X)?
- gpderetta 2y ago
  Not very many languages have compile time reflection. This is more like macros and syntax splicing. Still a reflect keyword could have worked. Some argued that in reflection heavy code you would reflect a lot and the keyword would be a lot of noise. I don't know if the reflection papers have been voted in already (I forgot how to check), so the syntax might still be up for debate.
- edflsafoiewq 2y ago
  According to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r10.html#syntax-discussion https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29... > The original TS landed on reflexpr(...) as the syntax to reflect source constructs and [P1240R0] adopted that syntax as well. As more examples were discussed, it became clear that that syntax was both (a) too “heavy” and (b) insufficiently distinct from a function call. SG7 eventually agreed upon the prefix ^ operator. The “upward arrow” interpretation of the caret matches the “lift” or “raise” verbs that are sometimes used to describe the reflection operation in other contexts.

thechao 2y ago

I tried pitching "generalized overloads" to Bjarne on a few occasions: `operator .` is highly problematic (you can read about it); but a number of the other `operator`s seem to be ok: `;`, `?:`, `if`, `for`, `while`, `switch-case`. Where things get challenging are: `goto-label` (just... mechanically). And, finally, do we want to overload aggregate & enumeration declaration? `typedef` declaration (this gets into name unification which is really awkward in templated contexts); function definitions, etc.). My argument was "leave that for C++14". For 90% of the code I was looking at the statement-level `operator`s solved the problems I had: it promoted the body of the functions into plain-old-template metaprogramming. Templated return types (a la Veldhuizen) converted function definitions into first class types that let me operate on functions, just like we've always done.

lpapez 2y ago
Thankfully I no longer work with C++, but such proposals were my main problem with the language. I had the impression that the vast majority of us regular users just wanted quality of life improvements: better error messages, networking library, a standard package manager etc. Literally most of what C++ code styles are concerned with is about picking what features are banned in that particular style. But instead of doing something pratical, the commitee always went with the route of adding increasingly niche features citing that useful things are "out of scope" or "implementation defined" or "userspace". So what you get is incompatible ecosystems and cultures for an extremely complicated language. Very happy working with Go presently, where exactly the opposite approach is being taken by maintainers. Eg: There was huge pushback regarding generics introduction (a genuinely useful language feature IMO), but they introduced very good vulnerability scanning (govulncheck) without me even hearing about it being under development.
- gpderetta 2y ago
  People want better error messages, networking, a package manager, etc. But they also want compile time reflection. Sometimes it is even the same people!
  - 2y ago

Aardwolf 2y ago

To me it's the ^^, like in ``` void print_members(T const& obj) { [:expand(nonstatic_data_members_of(^^T)):] ``` What is this ^^?

edflsafoiewq 2y ago
It's the reflection operator. Reflection is supposed to be part of the yet-unreleased C++26, so it's not surprising you don't know it.
pjmlp 2y ago
It was supposed to be only one ^ however it conflicts with Objective-C blocks, so they ended up settling on two ^^. However many of us would have prefered reflect(T), but again many on WG21 seem to use notepad for programming and don't like to type. It means the reflection data of the type.
- misnome 2y ago
  > however it conflicts with Objective-C blocks, so they ended up settling on two ^^. Which… were never added to C++, right? What a mess.
  - pjmlp 2y ago
    No, they are Objective-C only, and since there is this thing called Objective-C++, where one can combine Objective-C and C++ on the same source file, an alternative had to be chosen. Personally I would rather have reflect.
- saelthavron 2y ago
  > it conflicts with Objective-C blocks Why does that matter? > many of us would have prefered reflect(T), but again many on WG21 seem to use notepad for programming and don't like to type. I don't know about anyone else, but I find reflect(T) much easier to type than ^^T. I have a high error rate on hitting 6. Not only that I have to move my hand from the home row to hit it.

Wumpnot 2y ago

It is using c++ 26 features, so of course it looks slightly alien, nobody uses it yet.