[over.match.funcs.general] (original) (raw)

12 Overloading [over]

12.2 Overload resolution [over.match]

12.2.2 Candidate functions and argument lists [over.match.funcs]

12.2.2.1 General [over.match.funcs.general]

The subclauses of [over.match.funcs] describe the set of candidate functions and the argument list submitted to overload resolution in each context in which overload resolution is used.

The source transformations and constructions defined in these subclauses are only for the purpose of describing the overload resolution process.

An implementation is not required to use such transformations and constructions.

The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list.

If a member function is

it is considered to have an extra first parameter, called the implicit object parameter, which represents the object for which the member function has been called.

Similarly, when appropriate, the context can construct an argument list that contains animplied object argumentas the first argument in the list to denote the object to be operated on.

For implicit object member functions, the type of the implicit object parameter is

whereXis the class of which the function is a direct member andcvis the cv-qualification on the member function declaration.

[Example 1:

For aconstmember function of classX, the extra parameter is assumed to have type “lvalue reference toconst X”.

— _end example_]

For conversion functions that are implicit object member functions, the function is considered to be a member of the class of the implied object argument for the purpose of defining the type of the implicit object parameter.

For non-conversion functions that are implicit object member functions nominated by a using-declarationin a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter.

For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded).

[Note 1:

No actual type is established for the implicit object parameter of a static member function, and no attempt will be made to determine a conversion sequence for that parameter ([over.match.best]).

— _end note_]

During overload resolution, the implied object argument is indistinguishable from other arguments.

The implicit object parameter, however, retains its identity since no user-defined conversions can be applied to achieve a type match with it.

For implicit object member functions declared without a ref-qualifier, even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.

[Note 2:

The fact that such an argument is an rvalue does not affect the ranking of implicit conversion sequences.

— _end note_]

Because other than in list-initialization only one user-defined conversion is allowed in an implicit conversion sequence, special rules apply when selecting the best user-defined conversion ([over.match.best], [over.best.ics]).

[Example 2: class T { public: T();};class C : T { public: C(int);}; T a = 1; — _end example_]

In each case where conversion functions of a class S are considered for initializing an object or reference of type T, the candidate functions include the result of a search for the conversion-function-id operator Tin S.

[Note 3:

This search can find a specialization of a conversion function template ([basic.lookup]).

— _end note_]

Each such case also defines sets of permissible typesfor explicit and non-explicit conversion functions; each (non-template) conversion function that

is also a candidate function.

If initializing an object, for any permissible type cv U, any_cv2_ U, cv2 U&, or cv2 U&&is also a permissible type.

If the set of permissible types for explicit conversion functions is empty, any candidates that are explicit are discarded.

In each case where a candidate is a function template, candidate function template specializations are generated using template argument deduction ([temp.over], [temp.deduct]).

If a constructor template or conversion function template has an explicit-specifierwhose constant-expression is value-dependent ([temp.dep]), template argument deduction is performed first and then, if the context admits only candidates that are not explicit and the generated specialization is explicit ([dcl.fct.spec]), it will be removed from the candidate set.

Those candidates are then handled as candidate functions in the usual way.99

A given name can refer to, or a conversion can consider, one or more function templates as well as a set of non-template functions.

In such a case, the candidate functions generated from each function template are combined with the set of non-template candidate functions.

A defaulted move special member function ([class.copy.ctor], [class.copy.assign]) that is defined as deleted is excluded from the set of candidate functions in all contexts.

A constructor inherited from class type C ([class.inhctor.init]) that has a first parameter of type “reference to cv1 P” (including such a constructor instantiated from a template) is excluded from the set of candidate functions when constructing an object of type cv2 Dif the argument list has exactly one argument andC is reference-related to P andP is reference-related to D.

[Example 3: struct A { A(); A(A &&); template<typename T> A(T &&); };struct B : A { using A::A; B(const B &); B(B &&) = default; struct X { X(X &&) = delete; } x;};extern B b1; B b2 = static_cast<B&&>(b1); struct C { operator B&&(); }; B b3 = C(); — _end example_]