[llvm-bugs] [Bug 51887] Unambiguous use of operator==considered ambiguous.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51887

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> ---
The candidates here are:

1. bool operator==(T const&, T const&)
  with T = S<0>

2. bool operator==(S<I> const&, S<J> const&)
  from S<I>::operator==
  with I = 0, J = 0

In both cases, we have an identity conversion for both arguments. So the
candidates are not ordered by their argument conversions.

Next we consider whether one of the functions is more specialized than the
other. Deduction of the template arguments of (1) from (2) fails because we
deduce two different values for `T`. Deduction of the template arguments of (2)
from (1) fails because `T` is not of the form `S<I>`. So the templates are
unordered.

None of the other overload resolution tie-breakers apply either, so the call is
ambiguous.

EDG's compiler also rejects this in its conforming mode, but accepts in its
GCC-compatible mode, which tends to suggest that this is a GCC bug.

I also think that ambiguity is the expected result here: candidate (1) will
compare any two values of the same type, whereas candidate (2) will compare any
two Ss with potentially different I values. If we have two Ss with the same I,
it is not clear which one to use -- neither is looking for a more specific
situation.

Tentatively marking this invalid, but if you can point to where in the C++
standard it's specified that one of these two candidates is considered better,
we can revisit this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210924/0b29c7a5/attachment.html>