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 representationof reflections. Roughly, while P1240 has something equivalent tostruct 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 lattercauses 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 canalways 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