I'm reading the 1240 and I'm unsure if all reflection happens during instantiation. In the first example it reflects on ^T to get the enumerators, so it must happen at instantation when the exact enum is known. This said the reflection of an UTP or UA would benefit from functions like the is_value trait, and maybe an enum over all kinds. If reflection occurs after substitution only that enum will not contain "dependent" though.
The second thing I noted was that they have disambiguation of spliced reflections. When these disambiguations are needed will be reduced thanks to our deferred kind check just like UTPs, I suppose. There could be some issue there as reflections can represent both a value and its type, but this should be possible to resolve by the simple rule that [:^X:] shall always work like just X in a template-argument context. This would however warrant a longer investigation. There is interesting material on page 18 and 21 of P1240R2.
On page 23 the function parameters_of applied to a template returns reflections of the template parameters so a UTP would have to reflect in a special way here. For UAs this would work like type aliases on page 10, although I don't properly understand how that is.
On page 29 there are a plethora of predicates, and an is_dependent should already be there I think which would be true for UTPs retrieved using parameters_of. This should be true also for ^T::name but then again, as relfection occurs after substitution probably not, or there is work to do there, there does not seem to be a way to detect T::name as dependent, and I'm less convinced this has any value.
Their example on page 43 should be rewritten to handle any kind of template parameters. We should also see how an implementation using UTPs but no reflection would deal with this. On page 44 this limitation is discussed.
I'm reading the 1240 and I'm unsure if all reflection happens during instantiation. In the first example it reflects on ^T to get the enumerators, so it must happen at instantation when the exact enum is known. This said the reflection of an UTP or UA would benefit from functions like the is_value trait, and maybe an enum over all kinds. If reflection occurs after substitution only that enum will not contain "dependent" though.
The second thing I noted was that they have disambiguation of spliced reflections. When these disambiguations are needed will be reduced thanks to our deferred kind check just like UTPs, I suppose. There could be some issue there as reflections can represent both a value and its type, but this should be possible to resolve by the simple rule that [:^X:] shall always work like just X in a template-argument context. This would however warrant a longer investigation. There is interesting material on page 18 and 21 of P1240R2.
On page 23 the function parameters_of applied to a template returns reflections of the template parameters so a UTP would have to reflect in a special way here. For UAs this would work like type aliases on page 10, although I don't properly understand how that is.
On page 29 there are a plethora of predicates, and an is_dependent should already be there I think which would be true for UTPs retrieved using parameters_of. This should be true also for ^T::name but then again, as relfection occurs after substitution probably not, or there is work to do there, there does not seem to be a way to detect T::name as dependent, and I'm less convinced this has any value.
Their example on page 43 should be rewritten to handle any kind of template parameters. We should also see how an implementation using UTPs but no reflection would deal with this. On page 44 this limitation is discussed.