12 Overloading [over]

12.2 Overload resolution [over.match]

12.2.4 Best viable function [over.match.best]

12.2.4.2 Implicit conversion sequences [over.best.ics]

12.2.4.2.1 General [over.best.ics.general]

An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called.

The sequence of conversions is an implicit conversion as defined in [conv], which means it is governed by the rules for initialization of an object or reference by a single expression ([dcl.init], [dcl.init.ref]).

Implicit conversion sequences are concerned only with the type, cv-qualification, and value category of the argument and how these are converted to match the corresponding properties of the parameter.

[Note 1:

Other properties, such as the lifetime, storage duration, linkage, alignment, accessibility of the argument, whether the argument is a bit-field, and whether a function is deleted, are ignored.

So, although an implicit conversion sequence can be defined for a given argument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in the final analysis.

— end note]

A well-formed implicit conversion sequence is one of the following forms:

However, if the target is

(4.1)
the first parameter of a constructor or
(4.2)
the object parameter of a user-defined conversion function

and the constructor or user-defined conversion function is a candidate by

(4.3)
[over.match.ctor], when the argument is the temporary in the second step of a class copy-initialization,
(4.4)
[over.match.copy], [over.match.conv], or [over.match.ref] (in all cases), or
(4.5)
the second phase of [over.match.list] when the initializer list has exactly one element that is itself an initializer list, and the target is the first parameter of a constructor of class X, and the conversion is to X or reference to cv X,

user-defined conversion sequences are not considered.

[Note 2:

These rules prevent more than one user-defined conversion from being applied during overload resolution, thereby avoiding infinite recursion.

— end note]

[Example 1: struct Y { Y(int); }; struct A { operator int(); }; Y y1 = A(); // error: A::operator int() is not a candidate struct X { X(); }; struct B { operator X(); }; B b; X x{{b}}; // error: B::operator X() is not a candidate — end example]

For the case where the parameter type is a reference, see [over.ics.ref].

When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression.

The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter.

[Note 3:

When the parameter has a class type, this is a conceptual conversion defined for the purposes of [over]; the actual initialization is defined in terms of constructors and is not a conversion.

— end note]

Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion.

[Example 2:

A parameter of type A can be initialized from an argument of type const A.

The implicit conversion sequence for that case is the identity sequence; it contains no “conversion” from const A to A.

— end example]

When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion.

When the parameter has a class type and the argument expression has a derived class type, the implicit conversion sequence is a derived-to-base conversion from the derived class to the base class.

A derived-to-base conversion has Conversion rank ([over.ics.scs]).

[Note 4:

There is no such standard conversion; this derived-to-base conversion exists only in the description of implicit conversion sequences.

— end note]

When the parameter is the implicit object parameter of a static member function, the implicit conversion sequence is a standard conversion sequence that is neither better nor worse than any other standard conversion sequence.

In all contexts, when converting to the implicit object parameter or when converting to the left operand of an assignment operation only standard conversion sequences are allowed.

[Note 5:

When a conversion to the explicit object parameter occurs, it can include user-defined conversion sequences.

— end note]

If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion ([over.ics.scs]).

If no sequence of conversions can be found to convert an argument to a parameter type, an implicit conversion sequence cannot be formed.

If there are multiple well-formed implicit conversion sequences converting the argument to the parameter type, the implicit conversion sequence associated with the parameter is defined to be the unique conversion sequence designated the ambiguous conversion sequence.

For the purpose of ranking implicit conversion sequences as described in [over.ics.rank], the ambiguous conversion sequence is treated as a user-defined conversion sequence that is indistinguishable from any other user-defined conversion sequence.

[Note 6:

This rule prevents a function from becoming non-viable because of an ambiguous conversion sequence for one of its parameters.

[Example 3: class B; class A { A (B&);}; class B { operator A (); }; class C { C (B&); }; void f(A) { } void f(C) { } B b; f(b); // error: ambiguous because there is a conversion b → C (via constructor) // and an (ambiguous) conversion b → A (via constructor or conversion function) void f(B) { } f(b); // OK, unambiguous — end example]

— end note]

If a function that uses the ambiguous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous.

The three forms of implicit conversion sequences mentioned above are defined in the following subclauses.