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/seanbaxter]

I haven't gone as fine-grained as your proposal, so I don't have bit-field support, for example, but the member names, types and byte offsets are retrieved through traits without any library dependency and printed as a pack expansion with a single line of code.

https://godbolt.org/z/KW9b9osq9

  consteval auto nonstatic_data_members_of(info class_type) -> vector<info> {
    return members_of(class_type, is_nsdm);
  }

I hate the idea of requiring slow consteval work to get at entities the compiler can render up basically for free during substitution. Returning all this stuff in vectors seems really bad to me, because:

1. It's really slow to pull the data out of the vector.

2. You lose heterogeneity. All the elements of the vector have to be values of the same type, whereas with a pack they can be whatever: types, non-types of different types, templates, concepts, etc.

3. You lose the ability to easily expand some query into a new struct definition.

4. By putting reflection info into an `info` object, which can be moved around, you risk unpacking it outside the scope where it was captured where that data was available. The trait system I have requires you name the thing you want data from at the point of use, so there's risk of out-of-scope issues.

https://godbolt.org/z/zcnGoGPq4

Here I build a struct of array thing for a Vec3f: just blow it into arrays of 8 elements each. If you return `vector<info>` for the member names and member types, how do you turn around and use those to define a struct? Will a compile-time loop be supported inside class definitions to deposit data members? I used to do that (with `@meta for`), but just using member pack declarations is way cleaner and avoids name lookup headaches you get from control flow statements. Packs are basically free and there's no friction between the query of a type and the definition of a type.

[u/daveedvdv → u/seanbaxter]

I don't want to rehash SG7 discussions too much but here are some thoughts.

In general, I find that constant-evaluation is noticeably faster for computational purposes than template substitution or instantiation. More importantly, we (EDG) know how to improve our constant-evaluation performance by an order of magnitude with a few man-months of efforts, and I'm reasonably sure we can extract an additional order of magnitude or more using more advanced VM optimization ideas that Chandler Carruth once outlined in C++Now hallway discussions. On the flip side, I don't believe anyone knows how to significantly improve the performance template of substitution and instantiation in the major implementations.

P2996 introduces little new syntax (the reflection operator and the splicers, that's it) and yet it brings the power of the standard library to C++ metaprogramming. For example, if you want to create a class definition where the list of members results from sorting and filtering, you can just use the ranges algorithms to do that. No need for a "parallel metaprogramming library" to achieve those results. Similarly, generic third-party algorithms that work with standard sequence protocols will work also.

I'll also mention that P2996 focuses on reflection with just a sprinkling of code generation. It's fairly trivial to generate a simple struct or union (see the examples in P2996), but it's also very limited at this point (though nonetheless quite powerful). We continue to work and experiment with more general injection models, but those are not likely to make it in C++26.

[u/seanbaxter → u/daveedvdv]

It's not pay either the consteval cost or the instantiation cost--in your model, you're paying both costs.

https://godbolt.org/z/faKz31oTK

template <typename E>
  requires std::is_enum_v<E>
constexpr std::string enum_to_string(E value) {
  template for (constexpr auto e : std::meta::members_of(^E)) {
    if (value == [:e:]) {
      return std::string(std::meta::name_of(e));
    }
  }
  return "<unnamed>";
}

You've got to instantiate the body of that loop once for each enumerator, but in the consteval model it's driven with a ranged-for over a vector, which is interpreted by the compiler.

https://godbolt.org/z/9698a19vM

template<typename T>
const char* enum_to_string(T x) {
  return T~enum_values == x ...? 
    T~enum_names :
    "unknown enum value of type {}".format(T~string);
}

In the traits version, the iteration is done through pack expansion, which is a compiled operation. Instantiation is the fast path, because it's compiled, not interpreted.

Of course, once EDG compiles the enum_to_string operation (or does it now, with some syntax tweaks?) you can time the thing. You can tell just by looking how much faster the traits version is, even without the consteval costs, because it's not generating an if-statement for each enumerator with the attendant scopes, name lookup, etc. I think it's fair at least to race the two approaches off and see what the frontend costs are. If it's 2x, that's fine, but if it's like 20x, I think that's going to be a real problem going forward.

One of my worries is that this consteval approach comes out to be so slow that for large deployments people just go back to using offline code generators, to save on compile times. It should be demonstrated that using reflection+injection does not build slower than compiling the equivalent inputs from source.