CWG3032 [temp.arg.general] Template argument grammar disambiguation rule versus template template-arguments

[hubert-reinterpretcast]

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

Reference (section label): temp.arg.general

Link to reflector thread (if any): N/A

Issue description:
https://wg21.link/temp.arg.general#3 says that the type-id interpretation is preferred over any "expression" interpretation of a template-argument. Template template-argument‌s are supposed to be id-expression‌s (https://wg21.link/temp.arg.template#1). Following the introduction of https://wg21.link/p0091r3 (class template argument deduction), most template template-argument‌s are ill-formed type-id‌s. See https://wg21.link/dcl.type.simple#3 and https://wg21.link/dcl.type.class.deduct. Even without P0091R3, the disambiguation rule also affects the usage of the usage of the injected-class-name of a class template as a template template-argument.

Consider:

void g();

template <typename T>
struct A {
  static void f() {
    g<A>((A *)0);
    g<A>((A *)0, 0);  // Clang, GCC, EDG accept; MSVC rejects
  }
};

template <typename T> void g(void *);
template <template <typename> class> void g(void *, int);

void h() { A<int>::f(); }

Suggested resolution:
Template arguments that are in the form a of (possibly dependent) "name" can perhaps be parsed as a new, preferred-by-disambiguation, grammar production for template-argument. The (semantic) forms of template argument can be updated to accept appropriate instances of the new grammar production. Not requiring typename for a name that is used as the template-argument for a type template parameter would be consistent with the class template injected-class-name behaviour of Clang, GCC, EDG, and MSVC.

[jensmaurer]

What's the outcome for the first call to g?

[hubert-reinterpretcast]

What's the outcome for the first call to g?

All compilers accept: https://godbolt.org/z/Wh46scW9M

[t3nsor]

Template arguments that are in the form a of (possibly dependent) "name" can perhaps be parsed as a new, preferred-by-disambiguation, grammar production for template-argument.

P2841R7 has changed the grammar in this area to remove id-expression as one of the forms of template argument.

(There's still the fact that I don't know what it means for a dependent name to match the nested-name-specifier(opt) template-name grammar production if it's not actually known what kind of entity the dependent name refers to.)

[hubert-reinterpretcast]

(There's still the fact that I don't know what it means for a dependent name to match the nested-name-specifier(opt) template-name grammar production if it's not actually known what kind of entity the dependent name refers to.)

It wouldn't match. Instead, it would be taken as a non-type non-template name in the template definition context. That's the difference between using the grammar productions that are associated with finding certain kinds of declared names and not using them. This result does not match the intent expressed in the adopted P1787R6 ("Declarations and where to find them") proposal.

Anyhow, the grammar is still ambiguous. If the argument is known to name an injected-class-name of a template, it is also a type. Similarly, if it is otherwise known to name a template, it is also a type-id with a placeholder for CTAD.

Discussions around D2996R10 ("Reflection for C++26") resulted in a solution built around qualified-reflection-name for the similar problem with the ^^ operator.

[jensmaurer]

CWG3032

[hubert-reinterpretcast]

@jensmaurer, P2996 has been updated to use reflection-name as the name of the grammar production.

Additionally, it may help to add the following example to the issue to cover the non-injected-class-name case.
In particular, the status quo for the A<Tmpl> case is not consistent with the direction established by P1787R6 ("Declarations and where to find them") that the template disambiguation is deprecated when not used for the purposes of introducing a template-argument-list. It is my understanding that this last problem was introduced by P2841R7 ("Concept and variable-template template-parameters").

I believe that the current wording yields the Clang behaviour, but the EDG behaviour is what we want (and what the strategy proposed for resolving the issue would give).

void g();

template <typename T>
struct A {
  static void f() {
    g<T::TT>((A *)0);
  }
};

template <typename T> void g(void *);
template <auto> void g(void *);
template <template <typename> class> void g(void *);

struct Expr { enum { TT = 0 }; };
struct Type { using TT = int; };
struct Tmpl { template <typename> struct TT; };
void h() {
  A<Expr>::f();  // all accept
  A<Type>::f();  // EDG and MSVC accept; GCC and Clang reject
  A<Tmpl>::f();  // EDG and MSVC accept; GCC and Clang reject
}

https://godbolt.org/z/dG8G86hKb

[jensmaurer]

I've added the example and a wording suggestion. CWG3032