https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119897
Bug ID: 119897
Summary: Conversion to any integer type succeeds, when should
be ambiguous
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This example:
struct X {
template <typename T>
operator T() const;
#if BOOL
operator bool() const;
#endif
};
bool check(X x, int v) {
return x == v;
}
The expected behavior is that this ambiguous, regardless of the presence of
BOOL, since [over.built] gives us a lot of equivalently viable candidates to
that operator== (we can convert to float, double, int, long, the unsigned
versions, ...)
But gcc's behavior is:
* with BOOL=0: doesn't compile, but the error says *no* match for operator==.
It's the correct result, but the diagnostic isn't quite right.
* with BOOL=1: does compile, selecting x.operator int().
But the presence of operator bool() shouldn't matter here, and there's no
reason to prefer operator int() over operator long() or operator float() or ...
