12 Overloading [over]

12.4 Overload resolution [over.match]

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

12.4.1.1 Function call syntax [over.match.call]

In a function call if the postfix-expression names at least one function or function template, overload resolution is applied as specified in [over.call.func].
If the postfix-expression denotes an object of class type, overload resolution is applied as specified in [over.call.object].
If the postfix-expression is the address of an overload set, overload resolution is applied using that set as described above.
If the function selected by overload resolution is a non-static member function, the program is ill-formed.
[Note
:
The resolution of the address of an overload set in other contexts is described in [over.over].
— end note
]

12.4.1.1.1 Call to named function [over.call.func]

Of interest in [over.call.func] are only those function calls in which the postfix-expression ultimately contains a name that denotes one or more functions that might be called.
Such a postfix-expression, perhaps nested arbitrarily deep in parentheses, has one of the following forms:
These represent two syntactic subcategories of function calls: qualified function calls and unqualified function calls.
In qualified function calls, the name to be resolved is an id-expression and is preceded by an -> or . operator.
Since the construct A->B is generally equivalent to (*A).B, the rest of [over] assumes, without loss of generality, that all member function calls have been normalized to the form that uses an object and the . operator.
Furthermore, [over] assumes that the postfix-expression that is the left operand of the . operator has type “cv T” where T denotes a class.118
Under this assumption, the id-expression in the call is looked up as a member function of T following the rules for looking up names in classes ([class.member.lookup]).
The function declarations found by that lookup constitute the set of candidate functions.
The argument list is the expression-list in the call augmented by the addition of the left operand of the . operator in the normalized member function call as the implied object argument ([over.match.funcs]).
In unqualified function calls, the name is not qualified by an -> or . operator and has the more general form of a primary-expression.
The name is looked up in the context of the function call following the normal rules for name lookup in expressions ([basic.lookup]).
The function declarations found by that lookup constitute the set of candidate functions.
Because of the rules for name lookup, the set of candidate functions consists (1) entirely of non-member functions or (2) entirely of member functions of some class T.
In case (1), the argument list is the same as the expression-list in the call.
In case (2), the argument list is the expression-list in the call augmented by the addition of an implied object argument as in a qualified function call.
If the keyword this is in scope and refers to class T, or a derived class of T, then the implied object argument is (*this).
If the keyword this is not in scope or refers to another class, then a contrived object of type T becomes the implied object argument.119
If the argument list is augmented by a contrived object and overload resolution selects one of the non-static member functions of T, the call is ill-formed.
Note that cv-qualifiers on the type of objects are significant in overload resolution for both glvalue and class prvalue objects.
An implied object argument must be contrived to correspond to the implicit object parameter attributed to member functions during overload resolution.
It is not used in the call to the selected function.
Since the member functions all have the same implicit object parameter, the contrived object will not be the cause to select or reject a function.

12.4.1.1.2 Call to object of class type [over.call.object]

If the postfix-expression E in the function call syntax evaluates to a class object of type “cv T”, then the set of candidate functions includes at least the function call operators of T.
The function call operators of T are obtained by ordinary lookup of the name operator() in the context of (E).operator().
In addition, for each non-explicit conversion function declared in T of the form where the optional cv-qualifier-seq is the same cv-qualification as, or a greater cv-qualification than, cv, and where conversion-type-id denotes the type “pointer to function of () returning R”, or the type “reference to pointer to function of () returning R”, or the type “reference to function of () returning R”, a surrogate call function with the unique name call-function and having the form
R call-function ( conversion-type-id  F, P a, , P a) { return F (a, , a); }
is also considered as a candidate function.
Similarly, surrogate call functions are added to the set of candidate functions for each non-explicit conversion function declared in a base class of T provided the function is not hidden within T by another intervening declaration.120
The argument list submitted to overload resolution consists of the argument expressions present in the function call syntax preceded by the implied object argument (E).
[Note
:
When comparing the call against the function call operators, the implied object argument is compared against the implicit object parameter of the function call operator.
When comparing the call against a surrogate call function, the implied object argument is compared against the first parameter of the surrogate call function.
The conversion function from which the surrogate call function was derived will be used in the conversion sequence for that parameter since it converts the implied object argument to the appropriate function pointer or reference required by that first parameter.
— end note
]
[Example
:
int f1(int);
int f2(float);
typedef int (*fp1)(int);
typedef int (*fp2)(float);
struct A {
  operator fp1() { return f1; }
  operator fp2() { return f2; }
} a;
int i = a(1);                   // calls f1 via pointer returned from conversion function
— end example
]
Note that this construction can yield candidate call functions that cannot be differentiated one from the other by overload resolution because they have identical declarations or differ only in their return type.
The call will be ambiguous if overload resolution cannot select a match to the call that is uniquely better than such undifferentiable functions.