(Sorry for the poor formatting - one more attempt)

Greetings list, 

I have been using home-grown reflection in one form or another in my game engine for close to 2 decades now (typically implemented with nasty macros and templates and a mix of compile time and runtime implementation - sort of like QT - but without MOC). 

I tend to use it for serialization to/from various forms, including by not limited to json, binary, codecs for scripting language bindings, GUI editor panels, object deep cloning, etc...

  

you can see an example unit test here:

So I definitely mix compile time and runtime reflection in that my code does indeed require a reflection initialization phase typically at the beginning of main() and that the new reflection spec seems to focus entirely on static-compile time reflection and that is cool.

I use type_info to build my system.

So let's get to a feature I would like the static system described in P2996R3 to support if at all possible (if it does not already).

I never have made a request to the standards committee before so bear with me..

the feature is either of:

namespace std::meta {

  consteval ::size_t hash_code(info);

  // OR

  consteval ::std::type_info type_of(info);

}

The point of std::meta::hash_code(info) is to 'connect' (via hash) a compile time reflection info object to a rtti based one so one can easily augment the static info. alternatively if you can construct a type_info from a std::meta::info then that would suffice. In the case of hash_code() - it would need to return the same hash_code as the type_info for the same type. (as per the type_info::hash_code statement "Returns an unspecified value (here denoted by hash code) such that for all std::type_info objects referring to the same type, their hash code is the same."

Maybe it already supports this, I could not tell from reading the spec.

For what it's worth, at least in game engines it is not always desirable to enumerate ALL members of a reflected class, sometimes you want to only enumerate 'tagged' members. It sounds like you can 'search' enumerated members in the current spec, but can the user "annotate" members with an arbitrary annotation scheme for which the annotations are used as compile time filtering criteria ?

Thanks,