[temp.arg.template]/1 now lets a template template parameter be used as a template template argument, but the compatibility bullets in /3 were never updated to match - they still only cover an argument denoting a class/alias template, variable template, or concept.
So this ordinary forwarding case has no wording making it well-formed:
template<template<class> class TT>
struct S { };
template<template<class> class UU>
void f() {
S<UU> s;
}UU is permitted by /1, but /3 never makes it compatible with TT, so the /4 non-pack match cannot succeed. GCC, Clang, MSVC, and EDG all accept it, so this looks like a missed follow-up to CWG3080 / P2841R7 -- the fix is just to add the template-template-parameter alternatives to the three bullets in /3, mirroring /1.
(Whether /5 is well-defined when A is itself a template template parameter is a separate question, not needed here.)
[temp.arg.template]/1 now lets a template template parameter be used as a template template argument, but the compatibility bullets in /3 were never updated to match - they still only cover an argument denoting a class/alias template, variable template, or concept.
So this ordinary forwarding case has no wording making it well-formed:
UUis permitted by /1, but /3 never makes it compatible withTT, so the /4 non-pack match cannot succeed. GCC, Clang, MSVC, and EDG all accept it, so this looks like a missed follow-up to CWG3080 / P2841R7 -- the fix is just to add the template-template-parameter alternatives to the three bullets in /3, mirroring /1.(Whether /5 is well-defined when
Ais itself a template template parameter is a separate question, not needed here.)