================
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -std=c++23 -verify %s
+
+namespace t1 {
+template<bool> struct enable_if { typedef void type; };
+template <class T> class Foo {};
+template <class X> constexpr bool check() { return true; }
+template <class X, class Enable = void> struct Bar {};
+
+template<class X> void func(Bar<X, typename enable_if<check<X>()>::type>) {}
+// expected-note@-1 {{candidate function}}
+
+template<class T> void func(Bar<Foo<T>>) {}
+// expected-note@-1 {{candidate function}}
+
+void g() {
+ func(Bar<Foo<int>>()); // expected-error {{call to 'func' is ambiguous}}
----------------
cor3ntin wrote:
Nah, I think this is contrived enough that it's unlikely to affect users.
And if it does we probably want to break them anyway... I'm not even sure what
the exact behavior that determines the order is here: Which do you think should
be more specialized?
Breaking code seems like a least worst options that making arbitrary ordering
decisions.
In general there are tons of bugs pertaining to default arguments and ordering
and we should fix them.
Adding more special cases to partial ordering seem like a bad idea.
If users find issues with the direction we can reconsider or divide a
transition strategy (like we did with template template parameter ordering)
And as explain in https://github.com/llvm/llvm-project/issues/18291 - we are
not self consistent
https://github.com/llvm/llvm-project/pull/100692
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
