(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:
https://github.com/tweakoz/orkid/blob/develop/ork.core/tests/reflectionclasses.inl#L32
https://github.com/tweakoz/orkid/blob/develop/ork.core/tests/reflectionclasses.cpp#L30
https://github.com/tweakoz/orkid/blob/develop/ork.core/tests/reflection.cpp#L20

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,

Michael T. Mayers
Aphid Systems Corporation