Hi SG7,

On Sat, Jan 15, 2022 at 7: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.


 
This sums it up pretty well.

Some hot takes:

IMO the differences in usability is pretty significant in many cases (showing this, is one of the main reasons why I started with the mirror API and the examples).
With the `foo(info mo)` functions you need to make them instantiation contexts somehow, to unreflect, which makes the code uglier.

Ideally my proposal would be to make the `__metaobject_id` (builtin sort-of-integer that represents a metaobject) an "official" type and define info as:

struct info {
  __metaobject_id reflection;
};

This would allow us to write an alternative API like mirror (for people like me, who are willing to take some compile-time hit, in exchange for the usability). Or even to have a dual reflection API in the standard (I'm sure this will be a very popular suggestion :P)

--Matus