https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658
--- Comment #3 from Ulrich Mutze <ulrichmutze at gmx dot de> --- (In reply to Martin Sebor from comment #1) > I believe the test case is invalid. > > In a call to an operator, operator overload resolution in [over.match.oper] > considers three sets of candidate functions: > 1) member candidates (operators defined as members one of the operands) > 2) non-member candidates (only non-member functions are considered) > 3) built-in candidates (operators that take types to which the operands can > be converted) > > In the test case, sets (1) and (2) are obviously empty. Set (3) is also > empty because there is no well-formed implicit conversion sequence > ([over.best.ics]) from Z1 to int (the conversion exists but would require > two user-defined conversions, one from Z1 to Z and another from Z to int; > such conversions are not well-formed). > > Like GCC, both Clang 3.8 and EDG eccp 3.11 also reject the program. > > The expression "Z(x0)+Z(x1)" is valid because the types of the operands are > Z and thus do not require the second implicit user-defined conversion that > makes set (3) above empty. I believe that (3) is not empty since Z + Z is defined by a member function in Z and the arguments of Z1 + Z1 can be implicitly converted to Z in a single step. The type int is not in the game when Z sum=x0+x1; is under consideration. The implicit conversion Z --> int was enabled simply to allow my function main to return a reasonable value (which is required to be of type int). Sorry for this misleading and superfluous complication in my code.
