> On Jan 31, 2022, at 5:44 PM, Daveed Vandevoorde via SG7 <sg7_at_[hidden]> wrote:
>
>
>
>> On Jan 30, 2022, at 8:02 AM, Jonathan O'Connor via SG7 <sg7_at_[hidden]> wrote:
>>
>> This is my final comment on the paper!
>>
>> Is entity(r) always equal to entity(entity(r))?
>
> Yes, even for the invalid cases (like "entity(entity(^(1+2)))”).

Speaking of invalid reflections, have you guys given any further thought to allowing for more strongly typed reflections? Not object-oriented (or at least not necessarily so) — just some kind of mechanism for the compiler to store the information that the type of ^(1+2) is an reflection of an integer-typed expression, so that semantic checks involving reflections could be performed in dependent contexts without requiring evaluation.

It just seems like an issue that is going to crop up in the future, particularly in the realm of injection. E.g. a class template might have a long chain of injections of reflections of other injected entities and so on, and without sufficient type info the compiler cannot know if it can produce a valid instantiation until all the dependencies are resolved and the reflections evaluated.

I’m not sure how strongly-typed reflection syntax could be done, only that it would be unpleasant (imagine how one would write, say, the type of an array of reflections of expressions each of whose type is a pointer to a function which returns a reflection of a class template with non-type parameters and…).

But as a result most users would use auto (or auto^ — see below) - so this type system would mostly be for the compiler’s benefit (as is probably the case with function types).

I don’t expect this can be definitively solved in the near term, I only ask a) some consideration be given to whether strongly-typed reflection/injection semantics will eventually be desired, and b) whether the choices made now leave open the possibility of such semantics.

Off the top of my head one alternative to meta::info would be to replace its usage with some reflection-specific variant on auto, e.g. auto^. And, in the specification you wouldn’t necessarily say that auto^ is a type, as meta::info was. Implementations could still use meta::info, conceivably — it just wouldn’t be in the specification.

Such a change might require saying that you can’t e.g. have a vector<auto^> of dissimilar reflection types (as you could with meta::info). Would that be a bad thing though? Do examples exist in which a vector of dissimilar reflection kinds is needed?

Aside from the semantic benefits, this might allow e.g. the template-instantiation vs. value implementation issue to be deferred; i.e. Matus’s implementation could conceivably implement this reflection library, without requiring a meta::info type.

(On the other hand, if it could just be said that reflections *might* be more strongly typed in the future, but that *if so* all such stronger types will always be implicitly convertible to meta::info, then perhaps meta::info already permits sufficient flexibility.)

>
> Daveed
>
>>
>> Regards,
>> Jonathan
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>
>> On Saturday, January 15th, 2022 at 17:41, Daveed Vandevoorde via SG7 <sg7_at_[hidden]> wrote:
>>
>>> SG7 mailing list
>>>
>>> SG7_at_[hidden]
>>>
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>> --
>> SG7 mailing list
>> SG7_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7