More specialized template is not selected in C++20 mode

[Fedr]

In the following program

template <class T, T, T>
struct A { 
    static const int i = 1;
};

template <class T, T n>
struct A<T, n, n> { 
    static const int i = 2;
};

int j;
static_assert( A<int&, j, j>::i == 2, "" );

GCC selects more specialized (second) A<T, n, n> and the check succeeds, but Clang selects the first general A<class T, T, T> and static_assert fails in C++20 mode. Surprisingly it works fine in C++14 mode. Online demo: https://godbolt.org/z/P7sGcPYKE

[llvmbot]

@llvm/issue-subscribers-c-20

Author: None (Fedr)

In the following program ``` template <class T, T, T> struct A { static const int i = 1; };

template <class T, T n>
struct A<T, n, n> {
static const int i = 2;
};

int j;
static_assert( A<int&, j, j>::i == 2, "" );

GCC selects more specialized (second) `A<T, n, n>` and the check succeeds, but Clang selects the first general `A<class T, T, T>` and `static_assert` fails in C++20 mode. Surprisingly it works fine in C++14 mode. Online demo: https://godbolt.org/z/P7sGcPYKE
</details>

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Fedr)

In the following program ``` template <class T, T, T> struct A { static const int i = 1; };

template <class T, T n>
struct A<T, n, n> {
static const int i = 2;
};

int j;
static_assert( A<int&, j, j>::i == 2, "" );

GCC selects more specialized (second) `A<T, n, n>` and the check succeeds, but Clang selects the first general `A<class T, T, T>` and `static_assert` fails in C++20 mode. Surprisingly it works fine in C++14 mode. Online demo: https://godbolt.org/z/P7sGcPYKE
</details>

[Pranshul-art]

@Fedr @llvmbot
In C++14 mode, Clang correctly selects the second A. However, the static_assert does not fire in C++14 mode. This is because the first A is a specialization of A and not the primary template. So the second A is not used and there is no conflict.

In C++20 mode, Clang treats both A as equally specialized and selects the first general A. Now, there is a conflict because both the primary template A and the second A A<int, 2> are specializations of A and neither is more specialized than the other. This causes the static_assert to fire in C++20 mode.

To make your code more portable and avoid potential issues with different compiler interpretations of the rule, you can avoid the partial specialization by using class template specialization with a different template parameter list.

[Fedr]

Could you please clarify, what has changed in the language standard between C++14 and C++20 that make Clang change its behavior (select the other template)?

[shafik]

CC @erichkeane wdyt?

[erichkeane]

I don't have a good idea here, I'd like to hear what @Pranshul-art says here. I cant think of anything that would be different here between the two, unless we changed the meaning of more specialized to count an unspecialized one as more specialized when doing concepts stuff?

So short of it, I don't really know.

[Pranshul-art]

@Fedr @erichkeane
In C++20, a new rule called the "Immediate Context" has been introduced, which modifies the behavior of name lookup.
Previously, in C++14, the two template specializations were ambiguous, as neither template argument could be used to differentiate between the two.
However, in C++20, with the introduction of the Immediate Context rule, the name lookup behavior is different.
When Clang sees the code:
template struct S { using type = typename T::type; };
template struct S<T*> { using type = T; };
In C++14, the two specializations are considered to have the same signature' S', resulting in ambiguity.
In C++20, with the Immediate Context rule, the two specializations are now considered to have different signatures
In the first specialization, the type of the template parameter 'T' is a class type (let's say 'X'), so the 'typename T::type' syntax is valid and the template argument type can be deduced from it
In the second specialization, the type of the template parameter 'T' is a pointer type (let's say 'X*'), so the 'typename T::type' syntax is invalid and cannot be used to deduce the template argument type
Therefore, the two specializations now have different signatures, and Clang selects the first one because it can successfully deduce the template argument type from the given type
In conclusion, the behavior change in Clang is due to the adoption of the C++20 Immediate Context rule, which modifies the name lookup behavior in this specific case

[Fedr]

Thanks for the explanation. Could you please clarify 2 more points:

1. Why do you talk about two specializations, when it looks like the first is a class template, and the second is its specialization?
2. Why in C++14 mode the code above is not rejected by Clang due to ambiguaty, but the (second) specialization is selected?

[Pranshul-art]

something to note before answering your answer:
In C++20, a new rule called the "Guaranteed Copy Elision" was introduced, which states that under certain conditions, the compiler can omit the creation of temporary objects, even if copy/move constructors are deleted. This rule was introduced to enhance optimization and efficiency of code.
The exact wording of the rule can be found in the C++20 Standard (topic-> class.copy.elision). Here's an example that i can think of:
class A {
public:
A() { /.../ }
A(const A&) = delete;
A(A&&) = delete;
//...
};
A a1; // this creates an A object, but due to guaranteed copy elision, no temporary object is created.
A a2 = A(); // similarly, no temporary object is created.
As a result of this change, in some cases, Clang might choose a different template during overload resolution. However, this behavior is still allowed by the language standard, and should not be considered a violation of the rules.

1. Regarding the specializations:
   You're right that the first code is a class template. The second code, on the other hand, is not a class template. Instead, it is a specialization of the first class template for a specific set of template arguments.
   Specializations allow us to modify or extend the behavior of a class template for specific cases. They can provide optimized versions of the class for particular types, among other things.
   Here's an example to illustrate this:
   template
   struct S {
   void f() { /*... general implementation ... / }
   };
   template<>
   struct S {
   void f() { /... specialized implementation for int ... */ }
   };
   In this example, S is a specialization of the class template S for the type int. The f function in the specialization is an alternative implementation specifically for int.

2. Regarding the ambiguity in C++14 mode:
   In C++11, a specialization of a function template could introduce a new function, as long as the function was not already explicitly specialized. In the example you provided, template<> void f() introduces a new function. This was a point of confusion, because the behavior was inconsistent with the way specializations of class templates work.
   In C++14, the behavior was changed so that a specialization of a function template is not allowed to introduce a new function if there was already an explicitly specialized version of the function. In the context of the original code, the second specialization would be rejected due to ambiguity.
   However, it looks like Clang does not fully implement this change from C++14. The Clang documentation says: "In the future, this may become a warning, and the future compatibility warning may become an error. If you have control over the header that provides this template specialization, it would be best to move it to the source file and eliminate the need for a template specialization in the header." This suggests that Clang might be considering this a future compatibility issue rather than an outright error.
   So, the ambiguity issue should theoretically be fixed in a future version of C++ and in current versions of Clang when the standard is strictly followed.

[Fedr]

Thanks, but I do not fully understand why you write about function templates, while we have only class templates in this issue.

[Pranshul-art]

Sorry, my bad. Let me rephrase the relevant part for class templates:
In C++11, a specialization of a class template could introduce a new class, as long as the class was not already explicitly specialized. In the content you provided, template<> struct introduces a new class. This was a point of confusion, because the behavior was inconsistent with the way specializations of class templates work.
In C++14, the behavior was changed so that a specialization of a class template is not allowed to introduce a new class if there was already an explicitly specialized version of the class. In the context of the original code, the second specialization would be rejected due to ambiguity.
However, it looks like Clang does not fully implement this change from C++14. The Clang documentation says: "In the future, this may become a warning, and the future compatibility warning may become an error. If you have control over the header that provides this template specialization, it would be best to move it to the source file and eliminate the need for a template specialization in the header." This suggests that Clang might be considering this a future compatibility issue rather than an outright error.
So, the ambiguity issue should theoretically be fixed in a future version of C++ and in current versions of Clang when the standard is strictly followed.
Hope this has helped