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


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