Question

The standard appears to provide two rules for distinguishing between implicit conversion sequences that involve user-defined conversion operators:

c++11

13.3.3 Best viable function [over.match.best]

[…] a viable function F1 is defined to be a better function than another viable function
F2 if […]

• the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and the
  standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the
  entity being initialized) is a better conversion sequence than the standard conversion sequence from
  the return type of F2 to the destination type.

13.3.3.2 Ranking implicit conversion sequences [over.ics.rank]

3 – Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of
the following rules applies: […]

• 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 or constructor or aggregate
  initialization and the second standard conversion sequence of U1 is better than the second standard
  conversion sequence of U2.

As I understand it, 13.3.3 allows the compiler to distinguish between different user-defined conversion operators, while 13.3.3.2 allows the compiler to distinguish between different functions (overloads of some function f) that each require a user-defined conversion in their arguments (see my sidebar to Given the following code (in GCC 4.3) , why is the conversion to reference called twice?).

Are there any other rules that can distinguish between user-defined conversion sequences? The answer at https://stackoverflow.com/a/1384044/567292 indicates that 13.3.3.2:3 can distinguish between user-defined conversion sequences based on the cv-qualification of the implicit object parameter (to a conversion operator) or of the single non-default parameter to a constructor or aggregate initialisation, but I don’t see how that can be relevant given that that would require comparison between the first standard conversion sequences of the respective user-defined conversion sequences, which the standard doesn’t appear to mention.

Supposing that S1 is better than S2, where S1 is the first standard conversion sequence of U1 and S2 is the first standard conversion sequence of U2, does it follow that U1 is better than U2? In other words, is this code well-formed?

struct A {
    operator int();
    operator char() const;
} a;
void foo(double);
int main() {
    foo(a);
}

g++ (4.5.1), Clang (3.0) and Comeau (4.3.10.1) accept it, preferring the non-const-qualified A::operator int(), but I’d expect it to be rejected as ambiguous and thus ill-formed. Is this a deficiency in the standard or in my understanding of it?

Answer 1

The trick here is that converting from a class type to a non-class type doesn’t actually rank any user-defined conversions as implicit conversion sequences.

struct A {
    operator int();
    operator char() const;
} a;
void foo(double);
int main() {
    foo(a);
}

In the expression foo(a), foo obviously names a non-overloaded non-member function. The call requires copy-initializing (8.5p14) the function parameter, of type double, using the single expression a, which is an lvalue of class type A.

Since the destination type double is not a cv-qualified class type but the source type A is, the candidate functions are defined by section 13.3.1.5, with S=A and T=double. Only conversion functions in class A and any base classes of A are considered. A conversion function is in the set of candidates if:

• It is not hidden in class A, and
• It is not explicit (since the context is copy-initialization), and
• A standard conversion sequence can convert the function’s return type (not including any reference qualifiers) to the destination type double.

Okay, both conversion functions qualify, so the candidate functions are

A::operator int();        // F1
A::operator char() const; // F2

Using the rules from 13.3.1p4, each function has the implicit object parameter as the only thing in its parameter list. F1‘s parameter list is “(lvalue reference to A)” and F2‘s parameter list is “(lvalue reference to const A)”.

Next we check that the functions are viable (13.3.2). Each function has one type in its parameter list, and there is one argument. Is there an implicit conversion sequence for each argument/parameter pair? Sure:

• ICS1(F1): Bind the implicit object parameter (type lvalue reference to A) to expression a (lvalue of type A).
• ICS1(F2): Bind the implicit object parameter (type lvalue reference to const A) to expression a (lvalue of type A).

Since there’s no derived-to-base conversion going on, these reference bindings are considered special cases of the identity conversion (13.3.3.1.4p1). Yup, both functions are viable.

Now we have to determine if one implicit conversion sequence is better than the other. This falls under the fifth sub-item in the big list in 13.3.3.2p3: both are reference bindings to the same type except for top-level cv-qualifiers. Since the referenced type for ICS1(F2) is more cv-qualified than the referenced type for ICS1(F1), ICS1(F1) is better than ICS1(F2).

Therefore F1, or A::operator int(), is the most viable function. And no user-defined conversions (with the strict definition of a type of ICS composed of SCS + (converting constructor or conversion function) + SCS) were even to be compared.

Now if foo were overloaded, user-defined conversions on the argument a would need to be compared. So then the user-defined conversion (identity + A::operator int() + int to double) would be compared to other implicit conversion sequences.