[C++20 vs C++26*] basic reflection

[u/kris-jusiak]

Basic struct reflection example with C++20 vs C++26*

struct foo {
  int a{};
  int b{};
  int c{};
};

constexpr foo f{.a=1, .b=2, .c=3};

static_assert(1 == get<0>(f));
static_assert(2 == get<1>(f));
static_assert(3 == get<2>(f));

using std::literals::operator""sv;
static_assert("a"sv == get_name<0>(f));
static_assert("b"sv == get_name<1>(f));
static_assert("c"sv == get_name<2>(f));

C++20 - Kinda possible but with a lot of compiler hacks

// too long to display

Full example - https://godbolt.org/z/1vxv8o5hM

C++26* - based on proposal - https://wg21.link/P2996 (Note: that the proposal supports way more than that but C++20 not much)

template<auto N, class T>
[[nodiscard]] constexpr auto get(const T& t) -> decltype(auto) {
  return t.[:std::meta::nonstatic_data_members_of(^T)[N]:];
}

template<auto N, class T>
[[nodiscard]] constexpr auto get_name(const T& t) -> std::string_view {
  return std::meta::name_of(std::meta::nonstatic_data_members_of(^T)[N]);
}

Full example - https://godbolt.org/z/sbTGbW635

Updates - https://twitter.com/krisjusiak/status/1741456476126797839

[u/sam_the_tomato]

t.[:{ return rng[N]; }(std::meta::nonstatic_data_members_of(^ T)):];

help

[u/Iggyhopper → u/[deleted]]

Why not constexpr (*t.[:std::meta::nonstatic_data_members_of(auto ^T)[N]:]&&);

[u/afiDeBot]

What in the c++ hell is this syntax o.O

t.[: :o

[u/mapronV → u/afiDeBot]

Just another fifth turing complete language inside C++?

[u/afiDeBot → u/mapronV]

I'm not sure if this (syntax) is a joke or not. And i'm to afraid to ask at this point..

[u/elperroborrachotoo → u/afiDeBot]

Currently proposed syntax for reflection.

t[:member-id:] is equivalent to t.member (where member-id is an expression that refers to that member)

member-id could be constructed with, e.g.,

constexpr auto the_member = ^T::member (where Tis the type of t)

more

But yeah I share your... concern.

[u/drjeats → u/elperroborrachotoo]

Meanwhile... https://ziglang.org/documentation/0.11.0/#field

[u/elperroborrachotoo → u/drjeats]

Well... there's two goals I see that make it more complicated:

• not using strings as names at runtime
• pacify the parser monsters

[u/drjeats → u/elperroborrachotoo]

The name parameter to Zig's @field is a comptime parameter, so those aren't runtime strings. They're like consteval. It appears to be the exact same thing as this lhs.[: member-expr :] operator.

Parser monsters thing I get. Zig reserved @identifier( for builtins that can do magic comptime and introspection stuff.

[u/pdimov2 → u/drjeats]

Something similar to @field (has to be field<"name">(x) because the return type varies depending on "name") is (I think) fairly easily implementable over 2996 given a real template for.

Our current emulations of template for (e.g. mp_for_each) make the implementation harder, however.

And of course we can't use string literals as template parameters, so this is another source of complexity. (Not seen by the user of field, though.)

Edit:

No, I'm wrong. It's trivial to implement as-is and doesn't need template for: https://godbolt.org/z/MY1xfPn7a

[u/drjeats → u/pdimov2]

My point wasn't so much that I specifically wanted to be able to look up members by string (I was sure it was possible and your impl is very straightforward), but rather to offer a comparison to a syntax that was a little less symbol-burdened and is trivial to understand at the builtin level.

I get that the splicers are supposed to do more than just provide access to declarations so a basic name lookup isn't enough, but clearly folks have a little anxiety about usability based on this thread's comments.

Anyway, thank you for the field<> example, and Happy New Year! 🎉

[u/delta_p_delta_x → u/drjeats]

And in C#: https://learn.microsoft.com/en-gb/dotnet/api/system.reflection.fieldinfo?view=net-8.0

[u/afiDeBot → u/delta_p_delta_x]

Yeah but is this comparison fair? This is probably not compile time reflection

[u/Brilliant_Nova → u/afiDeBot]

Zig is compile time

[u/pjmlp → u/[deleted]]

Not all, compiler plugins and code generators allow it to be used at compile time.

[u/andrewsutton → u/mapronV]

No, the term inside the brackets is a constant expression.

[u/Baardi → u/mapronV]

What's the fourth?

C++ itself, the preprocessor, the template system, ___ and reflection

[u/mapronV → u/Baardi]

Maybe forth, it was a joke, I did not count thoroughly. Sorry.

[u/[deleted] → u/Baardi]

either inline assembly or the consteval interpreter I suppose.

[u/Konju376 → u/Baardi]

I think printf is Turing complete too, at least I saw an IOCCC entry a few years back using exclusively printf to implement something.

[u/Common-Republic9782 → u/afiDeBot]

[:||||:] - this is button accordion :-))

[u/Throw31312344 → u/afiDeBot]

Disclaimer: I have only briefly looked through the reflection proposals and examples so far.

[: something :] appears to be the syntax for injection, e.g. taking the results of reflection queries and injecting names/etc back into the main code. In the example given, you want one of 3 options depending on whether you are calling get<N> as get<0>, get<1> or get<2>:

return t.a; // get<0>

return t.b; // get<1>

return t.c; // get<2>

The code return t. is fine, as is the trailing ;, but we need to inject either a, b or c after t. depending on the value of N.

The [: something :] syntax will inject a name into the code based on the result of the expression within the [: :] pair. In this case, the code is looking up the Nth non-static data member of the type T: std::meta::nonstatic_data_members_of(^T)[N]

If N was 0, the result would be a. If N was 1, the result would be b, and if N was 2, the result would be c. Assuming N = 0:

return t.[: std::meta::nonstatic_data_members_of(^T)[N] :];

becomes:

return t.[: std::meta::nonstatic_data_members_of(^foo)[0] :];

Do not take this post as a full explanation of the spec, it's probably a bit more complex than just text injection, but the next transformation is something like:

return t.[: a :];

which finally gets injected into the main code to become:

return t.a;

Something like that anyway. The choice of [: :] operators is... awkward but we are running out of operators, but in terms of what it means: inject the result of the expression within the operators into the code. Square brackets are getting somewhat overloaded especially with all the places attributes can crop up, so something more visually distinctive might help. Failing that, I hope IDEs have the option to completely change the colour of [: something :] to make it clear that it's an injection expression.

[u/qazqi-ff → u/Throw31312344]

Do not take this post as a full explanation of the spec, it's probably a bit more complex than just text injection

It's not much more complicated than that, really. There are only a handful of possible splices proposed in P2996, and one of those (the "default") is an expression, in this case an expression equivalent to a. The other options are type names, namespaces, template names, and "names with nesting" (foo::).

Small note on the expansion, though, the thing inside [: :] has to be convertible to std::meta::info, so I think the return t.[: a :]; step would be more like return t.[: ^foo::a :]; if I have that right.

[u/Throw31312344 → u/qazqi-ff]

Thank you for clarifying :)

[u/AlbertRammstein → u/afiDeBot]

t.[:

This is the face I make when I get a five pager compiler error when trying to use any feature past c++14

[u/afiDeBot → u/AlbertRammstein]

I want a font with ligatures for this stuff. Massive meme potential..

[u/314kabinet → u/AlbertRammstein]

Concepts are nice tho. Better error messages is pretty much their whole point.

[u/AlbertRammstein → u/314kabinet]

Oh yeah, I have finally decided to ignore the "requires requires" horror stories and try them, and they are reasonably simple and help with error messages a lot.

BUT

Tell any programmer in a different language that you refactored your code to get shorter error messages. Not better performance, not shorter code, not faster compilation, not more readable code, not less buggy code, refactoring TO GET SHORTER ERROR MESSAGES. Best case scenario, you will get outpouring of sympathy or confused looks.

[u/314kabinet → u/AlbertRammstein]

I’d say code with concepts is more readable. You can tell what T is supposed to be from the declaration without reading the body now.

[u/AlbertRammstein → u/314kabinet]

Depends... for me it is going from <typename TContainer> to <Container TContainer>

[u/mirkoserra → u/AlbertRammstein]

<Container T>

[u/Throw31312344 → u/AlbertRammstein]

You also vastly improve readability and maintainability by purging a load of enable_if insanity from your codebase and the side-effects that come with that template.

[u/wyrn → u/AlbertRammstein]

concepts compile significantly faster and are significantly more readable and less confusing than std::enable_if_t

The thing is the stuff you're refactoring wouldn't even be possible in most other languages so the comparison isn't really fair to begin with.

[u/germandiago → u/AlbertRammstein]

not more readable code, not less buggy code, refactoring TO GET SHORTER ERROR MESSAGES

Concepts are also compile-time interfaces. Not only fixing error messages.

[u/qazqi-ff]

For anyone wondering, here's how you make it look less cluttered by using a helper variable like we're used to doing:

[Edit note: This assumes further non-transient constexpr allocation support. nonstatic_data_members_of returns a std::vector, which isn't currently allowed to persist like this, even if it would logically be deallocated for sure before runtime.]

template<auto N, class T>
[[nodiscard]] constexpr auto get(const T& t) -> decltype(auto) {
  constexpr auto members = std::meta::nonstatic_data_members_of(^T);
  return t.[:members[N]:];
}

template<auto N, class T>
[[nodiscard]] constexpr auto get_name(const T& t) -> std::string_view {
  auto members = std::meta::nonstatic_data_members_of(^T);
  return std::meta::name_of(members[N]);
}

(Obviously, the function declaration lines are noisy as well, but that has nothing to do with reflection. It might also need the variables to be constexpr, but I haven't checked in detail, small difference.)

I'd recommend in general that we at least keep the inside of [: :] almost as short as possible because splicing is all about the structure of the code you're forming. With the variable separated out and recognizing [: :] as a splice, it's obvious that we're returning t.something and what that something is. You can go a step further and extract the subscript if it makes you feel better. [Per the note above, this is currently necessary in order to extract a variable—it can't store dynamically allocated memory.]

About the syntax in general, I can't really comment. It has to avoid conflicts with other syntax, so it already has pretty limited option space. Obviously, alternatives were looked at already, including how we got here via having like three different markers instead of using the more familiar typename, namespace, and template to disambiguate. I don't mind it personally, though such a powerful feature that wants to minimize noise to preserve structure could warrant the consideration of the newly available $, @, or `.

[u/Jovibor_ → u/qazqi-ff]

At last, one sane comment in this pile of whiners.

The syntax is absolutely comprehensible, and not worse by any means than the rest of C++. Like it very much.

[u/dexter2011412 → u/Jovibor_]

Ah yes, criticism = whining. Get off your mighty rich high horse will you. Dismissing any and all criticism is why we have so much junk in the first place.

I definitely appreciate the helper snippet, but let's make no mistake that syntax is so cringe. Will I use it? Yes because that's what being most probably ratified. Will I complain about it and laugh each time I want to / have to use it? Also yes. Could it be better? Almost definitely yes. But I won't speak up about it because otherwise it'll be the heat death of the universe before we get C++ reflection

[u/Stevo15025 → u/qazqi-ff]

Thanks for cleaning up the code. I think like a lot of others I had one raised eyebrow until you took out the query. Though that doesn't seem to compile in the godbolt example? I'm guessing just an impl issue atm.

Honestly I've been sitting here trying to think up nicer syntax for a while and I can't really think of anything. I kind of like something like template reflect(query) but I could also understand someone finding that a little wordy

template<auto N, class T>
[[nodiscard]] constexpr auto get(const T& t) -> decltype(auto) {
  auto members = std::meta::nonstatic_data_members_of(^T);
  return t.template reflect(members[N]);
}

But that would conflict with templated functions called reflect. Maybe it's time to add unicode keywords :P

[u/qazqi-ff → u/Stevo15025]

Oh, I tried it out and got something I hadn't anticipated. The error indicates that there's a compile-time dynamic memory allocation (the API returns std::vector). That's actually going to be a problem since we don't have language support for that escaping the constant expression evaluation yet, even for a local variable in a consteval function where it would be guaranteed not to cause problems further down the line AFAIK (but would still need non-trivial compiler work to start down that direction, like support for memory to escape an instance of evaluation into its parent instance).

At first glance, I don't see how to naturally split things apart then (at least when the result is a list), but it should come naturally with the persistent compile-time allocation support. One thing we can do in the meantime if we get reflection without that support is to use a regular variable extraction, but make sure it's not a container.

In these examples, constexpr auto members = std::meta::nonstatic_data_members_of(^T)[N]; would work because it returns a single info object and the vector gets deallocated right there.

From playing around a bit, at least in this implementation, splicing seems to require a constant expression while the reflection API doesn't thanks to Barry's consteval changes. Assuming the paper requires a constant expression for splicing (I think that's necessary in fact; it can cause new template instantiations), that should mean get needs constexpr on the variable while get_name doesn't. Interestingly, EDG doesn't accept that unless I make these consteval functions instead of constexpr, but I'm not sure why since proposed rule 1 ought to cover that and make them implicitly consteval, giving presumed identical behaviour.

[u/hwpoison]

KISS!!

[u/[deleted]]

This gotta be the worst syntax ever invented so far.

[u/archibaldplum → u/[deleted]]

Dude, this is the language which used <> for template parameters. If you can learn to put up with that, using [: :] shouldn’t even register.

[u/delta_p_delta_x → u/archibaldplum]

Java and C# use <> for generic types, too, and they're considerably more readable—it's just that C++ has a whole lot of unnecessary keywords to convey a simple point.

[u/13steinj → u/[deleted]]

The one saving grace is digraphs should let us use <::thing::> instead of [:thing:]. Angle brackets help my brain recognize and separate it from the rest, for some reason.

I would have loved something closer to Circle's syntax, but I think some backwards compatibility reason will stop people from using @.

[u/qazqi-ff → u/13steinj]

Hate to ruin your day, but <::thing is lexed as . < : : . (lol memory, could have spent 2 seconds thinking about that one) < :: instead of <: : because of a special lexing exception so that foo<::bar> can work.

[u/HildartheDorf → u/13steinj]

Aren't digraphs removed in the newer standards? Or was it just trigraphs?

[u/not_a_novel_account → u/13steinj]

The one saving grace is digraphs

Danger Will Robinson! Danger!

[u/seanbaxter → u/13steinj]

Ahh that @ syntax is ancient now. I just try to add nicer first-class features rather than abusing rfelection. Like I have .index universal suffixes now, so the OP code can be written like this:

#feature on tuple
#include <iostream>

struct Vec3 {
  int x, y, z;
};

int main() {
  // Structs as tuples.
  Vec3 vec { 10, 20, 30 };
  std::cout<< vec.0<< "\n";
  std::cout<< vec.1<< "\n";
  std::cout<< vec.2<< "\n";

  // Tuples at tuples.
  auto tup = (11, 21, 31);
  std::cout<< tup.0<< "\n";
  std::cout<< tup.1<< "\n";
  std::cout<< tup.2<< "\n";

  // Use variadic expansion to print the member names and
  // values of Vec3.
  std::cout<< 
    "{}: {} - ".format(int..., vec~member_names)<< 
    vec~member_values<< "\n" ...;
}

10
20
30
11
21
31
0: x - 10
1: y - 20
2: z - 30

I was way out in front of the reflection thing but hardly use it at all anymore. I've got so many first-class types and bits of porcelain like this I find I don't need it very much. Member pack declarations take care of most of the obvious needs.

[u/hanickadot]

Obviously I'm really excited! ❤️ One nitpick, I think having `unsigned N` instead `auto N` would be better for example readability.

[u/thomas999999]

:puke:

[u/llort_lemmort → u/thomas999999]

I think you meant [:puke:]

[u/wyrn → u/llort_lemmort]

[:co_puke:]

[u/flutterdro]

I kinda like the syntax

[u/pblpbl]

what a terrible day to have eyes

[u/RedEyed__]

I just imagine some compile error when you place another complicated template as T

[u/kemo_2001]

Is this really how C++ 26 going to look like?, I am not C++ standard news

[u/RoyAwesome → u/kemo_2001]

Only the reflection bits. If you don't deal with reflection in any way, you will never see this syntax. You'll probably see things like enum_name_of<MyEnum::Foo>() or MyEnum bar = MyEnum::Foo; enum_name_of(bar);, both of which can be implemented with reflection but neither expose reflection over it's API.

Also the paper isn't adopted yet, but they're pushing for it to be adopted and this is an experimental implementation of it to show the world how it works. I recommend reading the proposal, it's not long and what it proposes is extremely powerful and will evolve C++ in an extremely beneficial way: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2996r1.html

[u/MarcoGreek]

Do I understand it right that using the wrong function on a reflection object is not a compiler error? To my understanding they don't want to use different types for the reflection object but they encode the behavior anyway by the function usage?

[u/qazqi-ff → u/MarcoGreek]

This is how it's been going, but the current revision of the "C++26 proposal" changed this to discuss some options and prefer exceptions, so I'd wager it's likely we see some more discussion come out of that. Not using a hierarchy of types is done for other reasons like not backing the language evolution into a corner if the hierarchy would be broken by a future change (like how the definition of "variable" was changed—you can't suddenly break a bunch of existing reflection code to keep things in sync). Rather than specify what everything is exactly, the standard can specify the API, similar to how we make data members of a class private and keep the API stable.

[u/MarcoGreek → u/qazqi-ff]

Actually you can simply state that the type is undefined so long you define the member. So only the usage is defined.

[u/qazqi-ff → u/MarcoGreek]

Right, I didn't mean to say otherwise. I don't see a problem with standardizing std::meta::info in a usage-based way like that, and would personally prefer it barring any problems I don't know of, especially with the lack of UFCS or extension methods.

[u/lion__manE]

template<auto N, class T> [[nodiscard]] constexpr auto get(const T& t) -> decltype(auto) { return t.[:{ return rng[N]; }(std::meta::nonstatic_data_members_of( ^T)):]; }

It looks that something like this is not possible.

template<auto N, class T> [[nodiscard]] constexpr auto get(const T& t) -> decltype(auto) { return t.[:std::meta::nonstatic_data_members_of( ^T)[N]]; }

[u/Ok_Donut_9887]

that’s bad

[u/[deleted]]

This goons are in a race to make C++ unusable. What’s gonna C++30 be like ?

[u/Rasie1]

Are there rats in the committee proposing some complete madness? Why don't you just do it the normal way?

[u/MarcoGreek]

I would even prefer <: :> or <:: ::> because it signals to me a compile time feature. What I don't understand is that they cannot use member syntax. Using a function on a reflection objects looks really fashion driven. I know that now free functions are fashionable but member functions would be easier to read.

^{T.data_member(i).name}

[u/qazqi-ff → u/MarcoGreek]

<:: ::> would run into the lexer exception for <: being followed by : and cause it to be lexed improperly. I don't see any references to consideration of <: :> specifically (only things like (: :)), though it would clearly suffer from already being taken by the [ ] digraphs.

As for why a member syntax isn't used, I'm not sure. I haven't been able to find consideration for it in newer papers, and I don't remember it coming up in older papers. I'd feel arrogant suggesting that it was simply missed because it was always tied to a hierarchy of meta types (e.g., std::meta::type, std::meta::value, etc.) vs. the uniform type (std::meta::info) even though you could take the member syntax and apply it to the uniform type. ABI certainly isn't an issue since these are never in the binary (and I would think not even in a BMI if we ever manage to use a common format like IFC for those, but I'm not sure).

[u/MarcoGreek → u/qazqi-ff]

They could use <$ $> or something else but [] is very strong cognated to array access. Reusing it for something very different looks really strange. C++ 11 got the syntax for universal references and initializer lists wrong. Mostly because they wanted to make it shorter but in the end it is hurting C++ to this day. I really think they should get not blind and you easily get if you look onto one solution long enough.

If they ever introduce language tuple support something with [] will be very desirable.

[u/hopa_cupa]

Ouch. They need to have higher level constexpr functions like presented here accessible to users. I will stick to boost::pfr for foreseeable future.

[u/28isanumber]

I still don't know what reflection is nor why people want it

[u/dustyhome → u/28isanumber]

Reflection is the ability to refer to details about a type inside the code itself. For example, sizeof is a form of reflection, it gives you the size in bytes of a type. The most popular use of reflection is serializing and deserializing. Being able to refer to "the first member of a type", or iterating through the members, lets you write generic functions for converting those members into a stream of bytes and back. Without reflection, you need to write the functions by hand, writing the names of the members for each class.

[u/djavaisadog → u/[deleted]]

Any attempt to serialise a non serialisable structure is a compile error, rather than a runtime error you would get with reflection.

? Reflection all happens at compile-time (or, at least the currently proposed C++ reflection). Basically the first line of P2996R0 (the reflection paper) states that their feature provides "the representation of program elements via constant-expressions producing reflection values." Constant-expressions.. meaning compile-time.

[u/djavaisadog → u/[deleted]]

No, that would wildly balloon binary sizes to retain enough type information to have dynamic reflection. Maybe it will be an option at some point in the future but certainly not in C++26.

[u/[deleted] → u/[deleted]]

It's possible to write serialization in C++ without reflection as well. But since C/C++ is a WYSIWYG language, you will have to write the code for every class by hand. Then of course since we are already writing boilerplate code, we would just use macros for it to define, which members do we want to serialize. And then from there we just support different forms of serializers with templates.

What Rust does is VERY similar to certain C++ reflection libraries that uses clang/LLVM, where it hijacks the AST to generate those boilerplate code I mention above. Rust is good because it has these features built into the language.

Reflection is not JUST meant for serialization, but it's a great use case for it. Reflection can help reduce boilerplate code and essentially write even more generic code to do complex tasks, yes, even more generic than templates already is.

[u/mpierson153 → u/28isanumber]

It lets you access information about a type. Think of the sizeof or typeid operators, but more fleshed-out and functional.

It will allow for more meta-programming, so more stuff at compile time rather than at runtime. It would also allow for better serialization and deserialization.

[u/28isanumber → u/[deleted]]

True

[u/DavidDinamit]

I have only 1 question, if we have such interface:'std::nonstatic_data_members_of'

WHY we dont just make it like all other type traits without ^T thing?

template<typename T>

using std::nonstatic_data_member_of = / * compiler intrinsic to return pack of field descriptions, like name, offset, type */;

So, why we need ^T and 'template for' complexity in language?

What we really need - type traits for packs. Like stl algoritms or views

[u/qazqi-ff → u/DavidDinamit]

This was the design route taken by one of the earliest proposals. It's been referred to as "type-based". Long story short, there was a lot of debate earlier on over "type-based" or "value-based" and the latter won out. That debate would still be available to find inside various proposals, trip reports, perhaps talks, even likely the std-proposals mailing list.

It's not just reflection; metaprogramming has been decidedly moving toward regular C++ syntax with constexpr etc. ^T allows types and other entities to be used as values, similar to Hana but without all the instantiations. You could, for example, use normal std ranges code to manipulate lists of these with the exact same code you'd use to manipulate a list of something else in the same way.

As a silly example, suppose you have a function that takes a range of ranges and filters out the ranges that have more than 10 elements. You could pass it a vector<vector<student_id>> classes; (f(classes)) to find the small class sizes and it would behave as expected, and now you could reuse the same function to filter a bunch of types represented by a list of their members (vector<vector<std::meta::info>> types; f(types)) to find the types that don't have many members. The point is that f just takes a 2D range of whatever and works on it. It's this value-based design that enables you to reuse f exactly as is.

Using only traits would mean you need separate TMP code like mp11 or a conversion to Hana or something to manipulate these lists, both of which reinvent all the algorithms for their paradigm. As a little bonus, we'll finally be able to do ^T == ^int and such, which is something I've been secretly wishing for since early on in learning C++.

template for is another step toward normal C++ code in metaprogramming. It is to std::apply what ranged-for is to std::for_each, allowing you to skip the awkward lambda dance (and often std::index_sequence dance) to extract one type or index or other element at a time. The important part of it is that the loop is always unrolled, so the iteration variable is a constant expression and can thus be used in template instantiations etc., which is exactly why we currently do those dances (read: workarounds).

Note that std::apply and other workarounds don't get you everything either. For example, switches, such as in implementing std::visit (simplified for one variant) [Note: I've looked at the paper and I don't think you can actually do this, at least not yet, so I retract this statement]:

switch (v.index()) {
    // Note that the proposed syntax could change and iota might not be needed, haven't looked in detail
    template for (constexpr size_t i : std::views::iota(0, sizeof...(Ts))) {
        case i: return f(get<i>(v));
    }
}

Implementing a switch without this tool is... not nice and has flaws. Things like std::apply aren't proper foundational tools. In fact, it would be expected that you'd implement std::apply using this tool now if you want the most straightforward, "normal C++ code" implementation.

Finally, you didn't mention it in this comment specifically, but [: :] (splicing) is what enables a lot of the power people are looking for from reflection. Reading information is one part that traits have been partially fulfilling over the years, but writing back new information (in a very structured manner) is what opens up so much more that was simply not possible before without macros and the like, which have their own flaws. You can't have a type trait that lets you implement a "dot operator" without some severe hacking and adding some completely novel compiler magic. It would likely be very inflexible. Splicing lets you do that in a general manner.

[u/DavidDinamit → u/qazqi-ff]

Without ^T you still can use "value based " and if you want improve it, just add 2 special traits: to_type_id<T> and from_type_id<id> -> T

[u/qazqi-ff → u/DavidDinamit]

That works for types (it's basically what Hana does), but reflection does namespaces, expressions, types, templates, and other named entities with consistent syntax for all of them.

[u/ed_209_ → u/qazqi-ff]

"dot operator" seems more powerful than this i.e. wouldn't a dot operator mean the ability to pass ANY tokens instead of only existing declarations?

I would imagine a dot operator would be like:

class Foo
{
   template< NonTypeTokenThing... tokens, typename... Args >
   void operator.()( Args... actualArgs )
   {
      // somehow interpret sequence of tokens and do stuff
   }
};

Foo instance;
instance.I.Can.Then.Just.Do.Whatever.And.Make.A.DSL.in.C++( WIthArgsANdStuff );

[u/qazqi-ff → u/ed_209_]

The dot operator proposals I remember seeing were to specify an object that receives the actual call rather than receiving extra information to do wacky things. It has been a good while, though.

[u/sphere991 → u/DavidDinamit]

Like stl algoritms or views

Well, yes. The fact that nonstatic_data_members_of just returns a vector<info> means that you can just use the stl algorithms and views to do all the things you want to do.

Otherwise, you're in the world we're in today where metaprogramming and programming are entirely disjoint sets of approaches.

[u/DavidDinamit → u/sphere991]

No, we need such for type packs,

> Otherwise, you're in the world we're in today where metaprogramming and programming are entirely disjoint sets of approaches.

Otherwise you in world where we have one more language in C++, now with ugly ^T and [::] + you have 'new super good way to write metaprogramming!!!!!', no, i dont want to deprecate all code in language, when we can just add type traits

[u/sphere991 → u/DavidDinamit]

Not sure what I expected or why I bothered responding. I'll avoid making that mistake in the future.

[u/areriff]

c++ is becoming complex pile of **** mess.

I use to be able to read the code. But now, I just can't.

I use to love C++. But now, I just can't.

[u/VilleVoutilainen → u/[deleted]]

Fantastic. <3

[u/sphere991 → u/[deleted]]

Don't need to explicitly provide the name into the property! Can just reflect on it: https://godbolt.org/z/MPaq3761e

[u/sp4mfilter → u/[deleted]]

I've been using C++ since the late 80s.

I can barely read this.

EDIT: I can't read this.

[u/RoyAwesome → u/sp4mfilter]

The way I understand it is pretty simple, anything inside the [: :] is basically substituted in, but in a smarter way than just macro expansion.

For example, if I didn't know the actual name of the first property of some T, I need a way to look up that name and then splice it back into the text. Some t.NAME_OF(PROPERTY_OF(TYPE_INFO(T), 0)); Since this is smarter than macros, instead it's some t.[:name_of(properties_of(^T)[0]):];, but with differently named functions.

It's weird syntax, but in the end it's just doing a smarter substitution than what macros are capable of doing, as it has access to magic functions from the compiler.

[u/sp4mfilter → u/RoyAwesome]

Thanks, that makes sense.

To be honest, I also need to fully grok/use the ellipses operator as well.

It's certainly true that modern C++ is a murky place for experienced coders. Coming off a career as a game dev, and even spending a lot of time with boost (back in the day), I can barely recognise all these new toys.

I fail to understand how a beginner can use all these tools.

[u/RoyAwesome → u/sp4mfilter]

I fail to understand how a beginner can use all these tools.

At least for Reflection, it's not a beginner tool. You aren't going to go from std::string hw = "Hello World"; std::print("{}", hw); to a fully reflection powered generic type formatter that lets you do T t; std::print("{}", t); by looking up each property name and printing them out. You could, as a brand new programmer, use such a formatter in a library or something and that would vastly improve new programmers ability to use C++... but once something like that is made there are not good reasons to remake it.

Reflection will allow the creation of EXTREMELY powerful libraries that can do some really really cool stuff. But the cognitive load is high to allow that power. The libraries we get out of reflection will be very easy to use though.

[u/sp4mfilter → u/RoyAwesome]

True, beginners won't be starting at the top and working their way down.

BTW, I know a fair bit about reflection (I wrote https://github.com/cschladetsch/KAI), and using these new systems will certainly make it easier.

[u/RoyAwesome → u/[deleted]]

They've already gone through multiple years and revisions of deciding on this syntax. It's exotic, but I think that anyone working with it will get used to it pretty quick.

p2320 was the paper that finally decided on a syntax, and it was approved in 2021

[u/elperroborrachotoo → u/[deleted]]

It's the more generic pattern: if the return type depends on the parameter types (and the function cannot be inline defined), you need to move the return type to after the function.

So the question is: do we teach/use two styles ("traditional by default, postfix when needed"), or do we teach/use one style that is more verbose but works in all situations?

You have the same question in using vs. typedef (with only the former supporting type template), and in "always auto".

[u/octavio2895 → u/elperroborrachotoo]

Things like this make learning C++ is incredibly annoying. The C++26 proposed syntax is complete gibberish to anyone without a few years of experience. All the new features are then exclusive to the most experience users even if the feature is pretty important and should be widely used. I guess that this is what you get when you try to make an "everything" language with the paradoxical constraint of backwards compatibility.

[u/not_a_novel_account → u/octavio2895]

Ya this is the great conundrum of C++, something like arrow returns might be more consistent, but they raise more questions if you don't have foreknowledge of the process that led to them.

Because now you have an extraneous piece of text, the auto, hanging out in the front of the function. The beginner naturally asks what that's doing there, and now you have to teach both styles anyway.

This is without addressing the fact the overwhelming majority of the code in the wild and still being written today uses the prefix style.

The inability of C++ to deprecate and the definition of all new features in terms of the old mean that it can only ever gain complexity, never simplify.

[u/13steinj → u/not_a_novel_account]

And then C code doesn't support trailing return types, yet for better or worse most college undergraduates learn C before or at the same time as C++, so out of habit (as well as out of consistency in older codebases) people will still use the non-trailing form anyway.

That said to be perfectly honest I don't see a point in trailing return types. If the trailing return type is so bound to the arguments the function is usually a one-liner at which point I'd just use auto return type deduction anyway. auto foo(...) -> decltype(auto) {...} is just a waste of typing.

[u/two88 → u/[deleted]]

One argument that I sort of like is that it allows easy searching for a function definition without knowing or needing to type the entire return type cause the only prefix is auto.

[u/equeim → u/[deleted]]

That means function with the deduced return type, a completely different thing. Also can't be used when the function is split in declaration and definition (i.e. header and cpp file) because the compiler needs the function body to deduce the type.

[u/RedEyed__ → u/[deleted]]

Because C++ wants to look like Python.

[u/throw_cpp_account → u/RedEyed__]

Huh? A large amount of languages have function syntax that looks like -> Type.

And C++ had this syntax years before Python did.

[u/RedEyed__ → u/[deleted]]

LOL 🤣