CWG3108 [expr.reflect] ^^type-id vs. type aliases

[jakubjelinek]

Full name of submitter (unless configured in github; will be published with the issue): Jakub Jelinek

Reference (section label): [expr.reflect]/6

Link to reflector thread (if any):

Issue description: The http://eel.is/c++draft/expr.reflect#6 wording only talks about specialization of an alias template as a way to get a type alias, but the examples later on and in https://eel.is/c++draft/basic.fundamental#example-2 show that ^^Alias where Alias is a typedef/using is a type alias.
In any case, it is unclear what exact type-ids should result in is_type_alias and what not.
https://godbolt.org/z/bdW5YGndc

#include <meta>

typedef int I;
static_assert (is_type_alias (^^I));
static_assert (!is_type_alias (^^const I));
static_assert (^^I != ^^int);
static_assert (^^const I == ^^const int);

typedef const int J;
static_assert (is_type_alias (^^J));
static_assert (!is_type_alias (^^const J));
static_assert (^^J != ^^const int);
static_assert (^^const J == ^^const int);

I'd think all this should pass, but the clang++ branch fails the first and third assert in the second block which is weird, ^^J IMHO is a type alias, what else? I'd think ^^const I shouldn't be a type alias because the reflection doesn't represent the type alias but its cv qualified version, but less sure about the ^^const J case where the type alias already contains the const; so, the only way to make ^^const J not a type alias would be during parsing of the type-id note that there are extra quals.

Suggested resolution:

[t3nsor]

See https://eel.is/c++draft/expr.reflect#5.6

Now that you point it out, I do find it odd that ^^I gives you a type alias whereas ^^const I does not, but that is what the wording says.

[jakubjelinek]

You're right.

[jakubjelinek]

Actually, isn't there an inconsistency between type aliases and specializations of alias templates?
If a type alias is only in the ^^ reflection-name case, then ^^I is a type alias but ^^const I or ^^I const is not.
template <typename T> using tmpl = cls <T>; ^^tmpl<int> is a type alias but what about ^^const tmpl<int> or ^^tmpl<int> const?

[katzdm]

Regretfully, the counterintuitive behavior that you're observing (i.e., ^^I represents a type alias, but ^^const I does not) is correct. More: This is exactly why type_of removes type aliases. const I is just a type-id, and neither a type nor a type alias; it's just a grammatical construct that ultimately names const int. In practice, this means that there's no requirement for the implementation to retain a separate record for const I. I wish it were otherwise, but I think this is as intended.

Likewise for alias template specializations: ^^tmpl<int> represents a type alias, but const tmpl<int> is just a type-id. And of course, same for const tmpl<int> &, which is just a type-id, even though tmpl<int> names a type alias.

[jakubjelinek]

Ok, note that the clang++ branch doesn't work that way, as seen on the using J = const int; is_type_alias (^^J) case.
Anyway, I'm wondering if the dealias alias stripping is supposed to be recursive.

typedef int I;
typedef const int J;
static_assert (^^I && == ^^int &&);
static_assert (^^J & == ^^const int &);

or when e.g. some var has const I & type whether type_of should yield ^^const int & or be a reference to const I.
In GCC we have a strip_typedefs function which does that recursively, reconstructing arrays/references/pointers/cv variants without aliases, but on the branch it is right now used in dealias solely for the case of when it is used on a type_alias, while alias & etc. aren't aliases. Though, when e.g. remove_pointer/remove_reference/remove_all_extent all do dealias, the only place that cares about aliases vs. non-aliases is reflection comparison, which surely needs to treat type alias vs. non-type alias as unequal, but supposedly for cv qualified or references/pointers/arrays of aliases should treat them as equal.

[jakubjelinek]

@katzdm Also, shall this pass?

template<typename> struct cls_tmpl {};
template<typename T> using cls_tmpl_alias = const cls_tmpl<T>;

static_assert (is_type_alias (^^cls_tmpl_alias <int>));
static_assert (!is_type_alias (^^const cls_tmpl_alias <int>));

Sadly, after parsing the type-id, the result is exactly the same in both cases. The reflection-name vs. type-id differentiation allows to differentiate that for non-template alias specializations by syntax and it is what the standard clearly says so, but for the template alias specialization, I don't see it worded clearly. Guess one could try to parse it as reflection-name and in case it yields an template alias, try to parse < template-argument-list[opt] > after it and if type-id parsing parses the same tokens, it is an type alias, otherwise not.

[jakubjelinek]

More complete testcase (or is there something that shouldn't pass?): https://godbolt.org/z/MdYoe3G43

[katzdm]

After chatting with Jakub offline, I think [expr.reflect]/6.2 is confusing. As it currently reads:

Otherwise, if the type-id names a type alias that is a specialization of an alias template ([temp.alias]), R represents that type alias.

The problem is that "names" could be read either of two ways:

1. The typeid is the name of the specialization of the alias template or
2. The name of the specialization of the alias template occurs within the type-id.

The former is what is intended, and I think we should say as much. I suggest the following change to [expr.reflect]/6.2:

Otherwise, if the type-id names is the typedef-name of a type alias that is a specialization of an alias template ([temp.alias]), R represents that type alias.

This confusion also demonstrates that another example could be helpful. Jakub recommended adding the following to the end of Example 3 of [expr.reflect]; I agree that it would be a good change:

typedef const struct X U;
template<typename T> using W = const S<T>;
static_assert(^^const U == ^^const X);             // ^^const U is not a type alias
static_assert(^^W<int> const == ^^const S<int>);    // ^^W<int> const is not a type alias

[jakubjelinek]

static_assert(^^W<int> const == ^^const S<int>; // ^^W<int> const is not a type alias
has missing ) before ;

[katzdm]

Thanks, fixed.

[jakubjelinek]

Couldn't this be worded based on the grammar? Like if the type-id is a simple-type-specifier which is the typedef-name of a type alias? Because I assume that is exactly what the compiler should test, that the type-id is in that case just simple-type-specifier and nothing else.

[katzdm]

Couldn't this be worded based on the grammar? Like if the type-id is a simple-type-specifier which is the typedef-name of a type alias? Because I assume that is exactly what the compiler should test, that the type-id is in that case just simple-type-specifier and nothing else.

Hmm I think we probably could. I believe the mention of the "specialization of an alias template" was intended to clarify that the "ordinary" type alias case falls under the parsing of a reflection name. But that seems sufficiently clear from the "it is interpreted as such" in [expr.reflect]/5.

[jensmaurer]

CWG3108