No match for non-type template template parameter

[n0F4x]

The following code compiles with 19.1.0 but not with 20.1.0

template <typename>
struct check {};

template <
    typename T,
    template <typename, T> typename Sequence_T,
    T value_T>
struct check<Sequence_T<T, value_T>> {
    constexpr static bool value = true;
};

template <typename T, T>
struct Sequence {};

static_assert(check<Sequence<int, 0>>::value);

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (n0F4x)

The following code compiles with 19.1.0 but not with 20.1.0

template <typename>
struct check {};

template <
    typename T,
    template <typename, T> typename Sequence_T,
    T value_T>
struct check<Sequence_T<T, value_T>> {
    constexpr static bool value = true;
};

template <typename T, T>
struct Sequence {};

static_assert(check<Sequence<int, 0>>::value);

[Endilll]

Clang 19 and other implementations accept this: https://godbolt.org/z/K4qcbfdfc, so sounds like a Clang 20 regression to me.

[llvmbot]

@llvm/issue-subscribers-c-1

Author: None (n0F4x)

The following code compiles with 19.1.0 but not with 20.1.0

template <typename>
struct check {};

template <
    typename T,
    template <typename, T> typename Sequence_T,
    T value_T>
struct check<Sequence_T<T, value_T>> {
    constexpr static bool value = true;
};

template <typename T, T>
struct Sequence {};

static_assert(check<Sequence<int, 0>>::value);

[cor3ntin]

@mizvekov

[mizvekov]

The code in the example reduces to: https://godbolt.org/z/rKq8WeW7e

Clang is now correct to reject this, and it should never have worked under what P0522 proposed.

Except for the so called 'pack-exception', P0522 only allowed matching template arguments to template template parameters when all valid uses of the parameter are also valid uses of the argument.

By accepting this, clang-19 and the other implementations are laundering a "class T, int" argument into a "class T, T" parameter, where in the argument the second parameter can only be a value of type int, but the template template parameter accepts a value of any type.

This leads to broken type checking by every other implementation. An example of the badness this allows: https://godbolt.org/z/bd6sEz6r9

In this case, I don't think there is anything wrong with the wording of P0522, this had just been implemented incorrectly.

This is the same as first reported here: #124137 (comment)
Originally responded here: #124137 (comment)

[AaronBallman]

FWIW, I am also getting reports of this same style of problem with our internal customers. Given how often people are hitting this, WG21 should probably be alerted that this DR is causing significant code breakage in the wild and perhaps may want to reconsider P0522 (at least as a DR). The issue our customer hit was with code like:

template <template <template <typename ...> class> class>
constexpr void instantiate() {
}
template <template <typename> class>
class A {
};
void axpbyz() {
  instantiate<A>();
}
template <template <typename, typename> class>
class B {
};
void instantiateB() {
  instantiate<B>();
}

[mizvekov]

The last one is a reproducer for a different problem: #130362
This has already been fixed in main, we just haven't back ported this yet to clang 20.

[mizvekov]

I don't think the issue in this ticket warrants a reconsideration of P0522, which has been a DR for almost 10 years.
The code in question cannot safely be used in many implementations due to bypassesing type checking pretty badly, as my last godbolt link shows.

[mizvekov]

(Besides the fact that the code in question would not work without P0522, so removing it as a DR does not really solve the question).