On Jan 15, 2022, at 1:39 PM, Peter Dimov via SG7 <sg7@lists.isocpp.org> wrote:

Daveed Vandevoorde wrote:
Hello reflecting friends,

(And Happy New Year!)

I’ve uploaded on the 2022 Teleconferences wiki for SG-7 an updated version
of P1240 (which has also been submitted for the next mailing).

Changes include:
— The syntax agreements that SG-7 voted through P2320 (e.g., prefix ^
instead of reflexpr(…) to create reflections)
— The proposed metafunctions now use span and string_view instead
of vector and string
— Various corrections and clarifications based on reader feedback and
implementation experience

I think that it might be worth discussing Matus's alternative representation
of reflections. Roughly, while P1240 has something equivalent to

struct info {  uintptr_t id; };

Matus instead suggests (if I understand correctly)

template<uintptr_t id> struct info {};

This implies that one does

   constexpr info x = ^T;

under P1240 and

   constexpr auto x = ^T;

under the hypothetical alternative.

The arguments against this are (again IIUC) performance - the latter
causes much more template instantiations because functions are like

   consteval some_func( auto refl );

instead of

   consteval some_func( info refl );

However, there's a difference in usability, too. In the first case, one can
always splice [:refl:] inside some_func (because it's an instantiation context),
whereas in the second case, one cannot.


That’s a massive price to pay, though (_every_ reflection value costs a type instance).  And if you’re willing to pay it, you can with P1240.  You can write:

template<info R> struct Refl { ... };

and now you have that same capability.

The reverse is not true.

(You could also write:

template<info refl> consteval some_func();

which is  slightly cheaper in terms of compilation resources and different notation.)

Daveed