The following example is likely wrongly discussed in standard text of
[over.match.class.deduct]

Such examples are also managed by the major compilers (gcc, mvsc, clang)
differently from the standard comments.

p6, Example 2:


template <class T> struct A { explicit A(const T&, ...) noexcept; // #1 A(T&
&, ...); // #2 }; int i; ... template <class T> A(const T&, const T&) -> A<T
&>; // #3 template <class T> explicit A(T&&, T&&) -> A<T>; // #4 ... A a7 =
{0, i}; // error: #3 deduces to A<int&>, #1 and #2 declare same constructor
A a8{0,i}; // error: #3 deduces to A<int&>, #1 and #2 declare same
constructor

The example reads that the selected guide is from the (user-defined)
deduction guide #3.

However, ok for #4 not matching, as there T is ambiguously deduced as int
from first function parameter and int& from second one.
Ok that #3 is better than #1 as the notional constructor related to #1 has
ellipsis, with lowest priority in overload resolution.
But, #2 is not worse than #3. Indeed, for #2 T is deduced as int and
A(int&&, ...) is the winner for the first argument.
Since #3 is the winner for second argument, here we have ambiguity.
Ambiguity is confirmed also by clang (that correctly lists #2 and #3 as
candidates), by mvsc (it lists also #4, a bit weird, but never mind), and
by gcc that just reads about argument deduction failed.

In conclusion, I guess that "#3 deduces to A<int&> is misleading.
Additionally, the statement "#1 and #2 declare same constructor" is also
misleading: they both matching the list-initialization with {0,i} and
deducing int, but they do not lead to the same constructor (const in& is
not int &&).



I hope you may also consider the following doubt that I was studying when I
found the problem above: