Overload resolution with multiple functions and multiple conversion operators

Question

Consider simple code :

#include<iostream>

struct A {
    operator double(){
        std::cout<<"Conversion function double chosen."<<std::endl;
        return 1.1;
    }
    operator char(){
        std::cout<<"Conversion function char chosen."<<std::endl;
        return 'a';
    }
} a;

void foo(int){}
void foo (char){}
int main() {
    foo(a);
}

Above code works fine, and as expected gcc, clang and VC++ chooses foo(char).

Now lets modify the code little bit :

#include<iostream>

struct A {
    operator double(){
        std::cout<<"Conversion function double chosen."<<std::endl;
        return 1.1;
    }
    operator char(){
        std::cout<<"Conversion function char chosen."<<std::endl;
        return 'a';
    }
} a;

void foo(int){}
void foo (double){} //parameter changed from char to double
int main() {
    foo(a);
}

Now this should have choose foo(double), but seems only VC++ is happy with the code while clang and gcc are unhappy with the above code.

main.cpp:11:10: error: call of overloaded 'foo(A&)' is ambiguous
 foo(a);
     ^
main.cpp:8:6: note: candidate: void foo(int)
 void foo(int){}
      ^
main.cpp:9:6: note: candidate: void foo(double)
 void foo (double){} //parameter changed from char to double
      ^

Can anyone explain why above code fails? or is it bug?.

One more question: Do gcc and clang share code of overload resolution?

Answer 1

A -> char is A -> char.

A -> int is A -> char -> int (because char to int is a promotion and so beats the double to int conversion).

A -> double is A -> double.

Two user-defined conversion sequences are only comparable if they involve the same user-defined conversion function. Thus, A -> char is a better conversion sequence than A -> int, so your first case is unambiguous. Neither A -> int nor A -> double is better than the other, so the second case is ambiguous.

Answer 2

TL;DR: The difference is that in the first case, as opposed to the second, the user-defined conversion sequences (A -> char, A -> int) call the same conversion function (operator char). That enables us to break the tie via [over.ics.rank]/(3.3).

---

The best conversion operators for particular functions are selected by [over.match.best]/(1.4) (comparing the conversion sequences of their return types).

Hence the better conversion function for foo(int) is operator char followed by a promotion to int, as opposed to operator double followed by a floating point conversion.

Now consider both variants of the second overload:

1. The best ICS to foo(char) is also via operator char (identity better than floating point conversion). Thus [over.ics.rank]/(3.3) is applicable:

   User-defined conversion sequence U1 is a better conversion sequence than another user-defined conversion sequence U2 if they contain the same user-defined conversion function […] and in either case the second standard conversion sequence of U1 is better than the second standard conversion sequence of U2.

   Hence the overall conversion to F2 is deemed better, and it is selected.

2. The best ICS to foo(double) is via operator double. We end up with two conversion sequences employing distinct conversion functions; nothing really applies, and we just get an ambiguity.