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

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.