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