C++ Logo

sg7

Advanced search

Re: [SG7] Update: P1240R2 — Scalable Reflection

From: Matus Chochlik <chochlik_at_[hidden]>
Date: Sat, 15 Jan 2022 20:39:33 +0100
Hi SG7,

On Sat, Jan 15, 2022 at 7:39 PM Peter Dimov via SG7 <sg7_at_[hidden]>
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

Received on 2022-01-15 19:39:45