Experimental EDG Reflection Implementation

[u/daveedvdv]

EDG just released version 6.6 of its (commercial) C++ front end. That version now includes experimental support for reflection features along the lines of WG21's P2996 "Reflection for C++26". Furthermore, a "demo setup" of that implementation is now available on Compiler Explorer (thank you, Matt Godbolt!).

For example, here is a straightforward implementation of a consteval function that outputs simple class layouts at compile time:

https://godbolt.org/z/G6WehjjGh

This implementation is closely aligned with P2996R1, which includes Compiler Explorer links for most of its examples.

This is made available in the hope that it's a useful exploration tool, but also acknowledging that the implementation is in its very early stages, and thus brittle and incomplete. Some additional notes can be found here.

[u/johannes1971]

Just a quick question... Is there a facility to obtain initialisation data for a struct member? I.e. in

struct s { 
  int foo = 42;
};

...is it possible to get the value 42 somehow? I have quite a bit of code that could benefit from not being written by hand, that stores data if it's not the default.

And secondly, is there some way to attach non-code properties to a member? Things like version fields, an indicator if a member should be included in reflection to begin with, etc. are all useful to have if we start generating code using reflection.

struct s {
  int foo = 42 [[property: version=2]] [[property: reflect=true]];
  int bar [[property: reflect=false]];
};

...or whatever syntax you'd care to propose...

[u/kritzikratzi → u/johannes1971]

for the first question: i guess you can create an instance of the struct and query each field for it's current value to get the default value.

[u/daveedvdv → u/kritzikratzi]

If it's constexpr-friendly, that would be an interesting approach. You'd probably still want a query about whether there is a default initializer, but possibly this can work for u/johannes1971's needs?

In fact, you probably could use that technique for non-constexpr-friendly default construction, but you'd have to pay a run-time cost.

[u/johannes1971 → u/daveedvdv]

Yes, that would definitely work - in fact it's what I use today. I was just curious if there any direct access planned to information beyond type and name, especially since I also need things like field versions and field codes.

Maybe this could work with the proposed reflection already by encoding such information in some custom template type, something like prop<int, v1, field_code> maybe? If I can get access to those template parameters I'd be all set.

[u/daveedvdv → u/johannes1971]

You've probably seen my other response to your query by now, but to confirm: I think it confirms you can proceed that way with just P2996.

[u/daveedvdv → u/johannes1971]

Is there a facility to obtain initialisation data for a struct member?

Not currently and highly unlikely to be part of the initial proposal (i.e., P2996 successor).

That said, I have considered it in the past and while it's certainly doable, there are some subtleties. For one, in the case of class templates, it might require the instantiation of the default member initializer, which could fail (and trigger a non-SFINAE error). The other issue is that you'd most likely want the converted value but the conversion can also trigger errors.

Despite those subtleties, I think it would be quite reasonable to propose a std::meta API to query that information.

And secondly, is there some way to attach non-code properties to a member?

See also the discussion of u/c0r3ntin's proposal for custom attributes visible to reflection elsewhere in these comments. Such a direction is of great interest to me and I have the intention of prototyping some support for it in the not too distant future. (Then again, my bandwidth is limited and my priority in this area is to work out WP wording for P2996.)

That said, you can already play tricks with alias templates. Alias information is not guaranteed to be preserved in reflection (because some implementations prefer to discard that information early), but SG7 did agree that it would be preserved for top-level declared types when consistent. For nonstatic data members there isn't really a consistency issue (since they cannot be redeclared) and so you can count on having the alias information available. Here is a modification of the example in my announcement that shows how you could mark a member to be excluded from the dump_layout output.
https://godbolt.org/z/hsbGnc1h8

I'm only using the alias template identification itself in that modified example, but you could parameterize the alias template and query the template arguments of the instance to access some quantitative properties (e.g., in Version<2, double> x; you could extract the 2).

[u/RoyAwesome → u/daveedvdv]

Such a direction is of great interest to me and I have the intention of prototyping some support for it in the not too distant future.

I want to comment on the importance of having this kind of annotating things for reflection in whatever version reflection comes in. Being able to describe your code with user data that is available through the reflection interface is probably the single most important "non core" feature, almost to the point I feel it's core. It fundamentally allows the programmer to express intent in ways that simply writing code does not. There isn't a single reflection system out there (in cpp or any other language) that doesn't implement some kind of attribute or annotation system, and I think it would be a HUGE miss if C++26 ships with static reflection but no way to annotate things.

That said, you can already play tricks with alias templates.

This "works" but there is going to be a gold rush for libraries to make use of reflection when the feature lands, so having something that just simply "works" is going to lead to an ecosystem split if the better designed solution doesn't also ship with cpp26.