Clang can't choose between operators int/bool for operator<

[Alcaro]

struct eee {
	operator int() const { return 5; }
	operator bool() const { return true; }
};

int main(int argc, char** argv)
{
	eee f;
	if (f < 0) {}
}

https://godbolt.org/z/4Gnfo4Pqf

Expected: There is no operator<(bool,int), so choosing operator<(int,int) would require the fewest conversion operations, and should be chosen.
Actual: Prints a dozen candidate operator<, and thinks operator<(float,int) is the most relevant one.

<source>:9:8: error: use of overloaded operator '<' is ambiguous (with operand types 'eee' and 'int')
    9 |         if (f < 0) {}
      |             ~ ^ ~
<source>:9:8: note: because of ambiguity in conversion of 'eee' to 'float'
<source>:2:2: note: candidate function
    2 |         operator int() const { return 5; }
      |         ^
<source>:3:2: note: candidate function
    3 |         operator bool() const { return true; }
      |         ^
<source>:9:8: note: built-in candidate operator<(float, int)
    9 |         if (f < 0) {}
      |               ^
<source>:9:8: note: built-in candidate operator<(double, int)
<source>:9:8: note: built-in candidate operator<(long double, int)
<source>:9:8: note: built-in candidate operator<(__float128, int)
<source>:9:8: note: built-in candidate operator<(int, int)
<source>:9:8: note: built-in candidate operator<(long, int)
<source>:9:8: note: built-in candidate operator<(long long, int)
<source>:9:8: note: built-in candidate operator<(__int128, int)
<source>:9:8: note: built-in candidate operator<(unsigned int, int)
<source>:9:8: note: built-in candidate operator<(unsigned long, int)
<source>:9:8: note: built-in candidate operator<(unsigned long long, int)
<source>:9:8: note: built-in candidate operator<(unsigned __int128, int)
1 error generated.

I think this is a rejects-valid (GCC, MSVC, and my intuition all agree that operator int() should be chosen), but even if it's instead an accepts-invalid in the others, naming float in the error is rather unhelpful, isn't it?

(Bonus issue: Change to operator float(), and Clang prints an error naming 146 different operator<. I think that one is also rejects-valid, for the same reason. https://godbolt.org/z/Y8joWar89)

[keinflue]

Clang is correct:

Suppose for simplicity we have only the overloads operator<(int, int) and operator<(float, int).

For operator(float, int), the conversion to float could use either operator int or operator float and neither is better choice than the other because the two both require a second standard conversion from integer to floating-point. Therefore the corresponding implicit conversion sequence on the argument is assigned the ambiguous conversion sequence.

The ambiguous conversion sequence is not considered better or worse than any other user-defined conversion sequence, therefore it is not worse than the corresponding conversion sequence on the first argument of operator<(int, int) even if that definitively would use operator int and wouldn't require any second standard conversion. This then makes overload resolution ambiguous.

Note that if you used function overloads

bool g(int, int);
bool g(float, int);

and called g(eee, 0) instead of using eee < 0, then GCC would agree and also consider this ambiguous. It seems to have special handling for operators that is not supported by the standard.

See also CWG 260 and CWG 507.

[keinflue]

The issue with the diagnostic not being intuitive seems to be the same as #10981.

[Alcaro]

How would you call operator float when there is no operator float? There are only operators bool and int. Sure, you can convert those to float, but why would you, when you can just use eee::operator int() and operator<(int,int)?

Yes, GCC rejects it if changing the operator to an overloaded function - but instead, MSVC accepts it. https://godbolt.org/z/hvfePKE8e

The compilers being inconsistent on those two is definitely bugs, but I can't confidently say if they're rejects-valid or accepts-invalid.

I can, however, confidently say that the C++ type system is a giant labyrinth.

[keinflue]

@Alcaro

I am just laying out what the rules in the standard say, not making a judgment whether these are good rules. Effectively, having multiple non-explicit conversion functions to arithmetic types is always going to make overload resolution difficult with the current overload resolution rules and should be avoided.

GCC is incorrect in accepting this without diagnostic, but it may be possible that this is intentional rather than a bug, because the standard-mandated behavior is inconvenient to the user. (There are other overload resolution scenarios in which GCC is more permissive than the standard rules.) Although I guess at least with -pedantic-errors it should reject it according to standard.

MSVC seems to reject the original example btw. (but for the wrong reason): https://godbolt.org/z/oKrr1fbvf

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Alcaro)

```c++ struct eee { operator int() const { return 5; } operator bool() const { return true; } };

int main(int argc, char** argv)
{
eee f;
if (f < 0) {}
}

https://godbolt.org/z/4Gnfo4Pqf

Expected: There is no operator<(bool,int), so choosing operator<(int,int) would require the fewest conversion operations, and should be chosen.
Actual: Prints a dozen candidate operator<, and thinks operator<(float,int) is the most relevant one.

<source>:9:8: error: use of overloaded operator '<' is ambiguous (with operand types 'eee' and 'int')
9 | if (f < 0) {}
| ~ ^ ~
<source>:9:8: note: because of ambiguity in conversion of 'eee' to 'float'
<source>:2:2: note: candidate function
2 | operator int() const { return 5; }
| ^
<source>:3:2: note: candidate function
3 | operator bool() const { return true; }
| ^
<source>:9:8: note: built-in candidate operator<(float, int)
9 | if (f < 0) {}
| ^
<source>:9:8: note: built-in candidate operator<(double, int)
<source>:9:8: note: built-in candidate operator<(long double, int)
<source>:9:8: note: built-in candidate operator<(__float128, int)
<source>:9:8: note: built-in candidate operator<(int, int)
<source>:9:8: note: built-in candidate operator<(long, int)
<source>:9:8: note: built-in candidate operator<(long long, int)
<source>:9:8: note: built-in candidate operator<(__int128, int)
<source>:9:8: note: built-in candidate operator<(unsigned int, int)
<source>:9:8: note: built-in candidate operator<(unsigned long, int)
<source>:9:8: note: built-in candidate operator<(unsigned long long, int)
<source>:9:8: note: built-in candidate operator<(unsigned __int128, int)
1 error generated.

I think this is a rejects-valid (GCC, MSVC, and my intuition all agree that operator int() should be chosen), but even if it's instead an accepts-invalid in the others, naming float in the error is rather unhelpful, isn't it?

(Bonus issue: Change to operator float(), and Clang prints an error naming 146 different operator<. I think that one is also rejects-valid, for the same reason. https://godbolt.org/z/Y8joWar89)
</details>

[shafik]

We have implementation divergence: https://godbolt.org/z/K64qcec4j

gcc/MSVC Vs clang/edg here.

This looks like a duplicate of: #122579

and the diagnostic portion of this issue is a dup of; #10981

Also related: #87517

[frederick-vs-ja]

How would you call operator float when there is no operator float? There are only operators bool and int. Sure, you can convert those to float, but why would you, when you can just use eee::operator int() and operator<(int,int)?

Looks like that a CWG issue is desired.

Oops. I misread this.

Perhaps we should disambiguate the following:

bool g(int, int);
bool g(float, int);