http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
--- Comment #1 from Johannes Schaub <schaub.johannes at googlemail dot com>
2010-12-28 19:10:25 UTC ---
It should be noted that this can yield to ambiguities in combination with other
conversion functions. Consider
enum E { };
struct A {
explicit operator int();
operator E();
};
bool operator!(E);
int main() {
!A(); // should work, but GCC rejects!
}
In this case, since GCC considers both "operator int" and "operator E" for the
contextual conversion to bool, but neither is better than the other, it assigns
the ambiguous conversion sequence for the builtin operator. For conversion to
the E-taking one, it unambiguously uses "operator E". Since the ambiguous
conversion sequence cannot be compared to any other conversion sequence, we
have an ambiguity between the builtin operator and our own defined one.
On a n3225-conforming implementation, both operator functions would use
"operator E", and then it would be found that "operator!(E)" matches the return
of the conversion function better than the built-in candidate, and would thus
be selected.
So it's really a "rejects-valid", as is basically any C++ issue of this sort
anyway, since they can all be "exploited" by using SFINAE.
