[over.ics.ref]

# 12 Overloading [[over]](./#over)

## 12.2 Overload resolution [[over.match]](over.match#over.ics.ref)

### 12.2.4 Best viable function [[over.match.best]](over.match.best#over.ics.ref)

#### 12.2.4.2 Implicit conversion sequences [[over.best.ics]](over.best.ics#over.ics.ref)

#### 12.2.4.2.5 Reference binding [over.ics.ref]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/overloading.tex#L2388)

When a parameter of type “reference to cv T”
binds directly ([[dcl.init.ref]](dcl.init.ref "9.5.4 References")) to an argument expression:

- [(1.1)](#1.1)

  If the argument expression has a type that
is a derived class of the parameter type,
the implicit conversion sequence is a derived-to-base
conversion ([[over.best.ics]](over.best.ics "12.2.4.2 Implicit conversion sequences"))[.](#1.1.sentence-1)

- [(1.2)](#1.2)

  Otherwise,
if the type of the argument is possibly cv-qualified T, or
if T is an array type of unknown bound with element type U and
the argument has an array type of known bound whose
element type is possibly cv-qualified U,
the implicit conversion sequence is the identity conversion[.](#1.2.sentence-1)

- [(1.3)](#1.3)

  Otherwise,
if T is a function type,
the implicit conversion sequence is a function pointer conversion[.](#1.3.sentence-1)

- [(1.4)](#1.4)

  Otherwise, the implicit conversion sequence is a qualification conversion[.](#1.4.sentence-1)

[*Example [1](#example-1)*: struct A {};struct B : public A {} b;int f(A&);int f(B&);int i = f(b); // calls f(B&), an exact match, rather than f(A&), a conversionvoid g() noexcept;int h(void (&)() noexcept); // #1int h(void (&)()); // #2int j = h(g); // calls #1, an exact match, rather than #2, a function pointer conversion — *end example*]

If the parameter binds directly to the result of
applying a conversion function to the argument expression, the implicit
conversion sequence is a user-defined conversion sequence ([[over.ics.user]](over.ics.user "12.2.4.2.3 User-defined conversion sequences"))
whose second standard conversion sequence is
determined by the above rules[.](#1.sentence-2)

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/overloading.tex#L2435)

When a parameter of reference type is not bound directly to an argument
expression, the conversion sequence is the one required to convert the argument
expression to the referenced type according to [[over.best.ics]](over.best.ics "12.2.4.2 Implicit conversion sequences")[.](#2.sentence-1)

Conceptually, this conversion sequence corresponds to copy-initializing a
temporary of the referenced type with the argument expression[.](#2.sentence-2)

Any difference
in top-level cv-qualification is subsumed by the initialization itself and
does not constitute a conversion[.](#2.sentence-3)

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/overloading.tex#L2445)

Except for an implicit object parameter, for which see [[over.match.funcs]](over.match.funcs "12.2.2 Candidate functions and argument lists"),
an implicit conversion sequence cannot be formed if it requires
binding an lvalue reference
other than a reference to a non-volatile const type
to an rvalue
or binding an rvalue reference to an lvalue of object type[.](#3.sentence-1)

[*Note [1](#note-1)*:

This means, for example, that a candidate function cannot be a viable
function if it has a non-const lvalue reference parameter (other than
the implicit object parameter) and the corresponding argument
would require a temporary to be created to initialize the lvalue
reference (see [[dcl.init.ref]](dcl.init.ref "9.5.4 References"))[.](#3.sentence-2)

— *end note*]

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/overloading.tex#L2460)

Other restrictions on binding a reference to a particular argument
that are not based on the types of the reference and the argument
do not affect the formation of an implicit conversion
sequence, however[.](#4.sentence-1)

[*Example [2](#example-2)*:

A function with an “lvalue reference to int” parameter can
be a viable candidate even if the corresponding argument is anint bit-field[.](#4.sentence-2)

The formation of implicit conversion sequences
treats theint bit-field as anint lvalue and finds an exact
match with the parameter[.](#4.sentence-3)

If the function is selected by overload
resolution, the call will nonetheless be ill-formed because of
the prohibition on binding a non-const lvalue reference to a bit-field ([[dcl.init.ref]](dcl.init.ref "9.5.4 References"))[.](#4.sentence-4)

— *end example*]