[over.match] - C++17 → C++20

Files changed (1) hide show

tmp/tmpaxppttzr/{from.md → to.md} +745 -352

tmp/tmpaxppttzr/{from.md → to.md} RENAMED Viewed

@@ -15,73 +15,73 @@ as the accessibility of the function, can make its use in the calling
 context ill-formed. — *end note*]
 Overload resolution selects the function to call in seven distinct
 contexts within the language:
-- invocation of a function named in the function call syntax (
-  [[over.call.func]]);
 - invocation of a function call operator, a pointer-to-function
   conversion function, a reference-to-pointer-to-function conversion
   function, or a reference-to-function conversion function on a class
-  object named in the function call syntax ([[over.call.object]]);
-- invocation of the operator referenced in an expression (
-  [[over.match.oper]]);
-- invocation of a constructor for default- or direct-initialization (
-  [[dcl.init]]) of a class object ([[over.match.ctor]]);
-- invocation of a user-defined conversion for copy-initialization (
-  [[dcl.init]]) of a class object ([[over.match.copy]]);
 - invocation of a conversion function for initialization of an object of
-  a non-class type from an expression of class type (
- [[over.match.conv]]); and
-- invocation of a conversion function for conversion to a glvalue or
- class prvalue to which a reference ([[dcl.init.ref]]) will be
-  directly bound ([[over.match.ref]]).
 Each of these contexts defines the set of candidate functions and the
 list of arguments in its own unique way. But, once the candidate
 functions and argument lists have been identified, the selection of the
 best function is the same in all cases:
 - First, a subset of the candidate functions (those that have the proper
   number of arguments and meet certain other conditions) is selected to
-  form a set of viable functions ([[over.match.viable]]).
 - Then the best viable function is selected based on the implicit
-  conversion sequences ([[over.best.ics]]) needed to match each
- argument to the corresponding parameter of each viable function.
 If a best viable function exists and is unique, overload resolution
 succeeds and produces it as the result. Otherwise overload resolution
 fails and the invocation is ill-formed. When overload resolution
-succeeds, and the best viable function is not accessible (Clause
-[[class.access]]) in the context in which it is used, the program is
 ill-formed.
 ### Candidate functions and argument lists <a id="over.match.funcs">[[over.match.funcs]]</a>
 The subclauses of  [[over.match.funcs]] describe the set of candidate
 functions and the argument list submitted to overload resolution in each
-of the seven contexts 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. So that
 argument and parameter lists are comparable within this heterogeneous
-set, a member function is considered to have an extra parameter, called
-the *implicit object parameter*, which represents the object for which
-the member function has been called. For the purposes of overload
 resolution, both static and non-static member functions have an implicit
 object parameter, but constructors do not.
 Similarly, when appropriate, the context can construct an argument list
-that contains an *implied object argument* to denote the object to be
-operated on. Since arguments and parameters are associated by position
-within their respective lists, the convention is that the implicit
-object parameter, if present, is always the first parameter and the
-implied object argument, if present, is always the first argument.
 For non-static member functions, the type of the implicit object
 parameter is
 - “lvalue reference to cv `X`” for functions declared without a
@@ -105,25 +105,25 @@ 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 non-static member functions
-declared without a *ref-qualifier*, an additional rule applies:
-- 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 (
-  [[over.ics.rank]]). — *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]]).
@@ -138,46 +138,80 @@ public:
 class C : T {
 public:
   C(int);
 };
-T a = 1;            // ill-formed: T(C(1)) not tried
 ```
 — *end example*]
 In each case where a candidate is a function template, candidate
 function template specializations are generated using template argument
-deduction ([[temp.over]], [[temp.deduct]]). Those candidates are then
-handled as candidate functions in the usual way.[^2] A given name can
-refer to one or more function templates and also to a set of overloaded
-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 constructor or assignment operator ([[class.copy]])
-that is defined as deleted is excluded from the set of candidate
-functions in all contexts.
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
-In a function call ([[expr.call]])
 ``` bnf
 postfix-expression '(' expression-listₒₚₜ ')'
 ```
-if the *postfix-expression* denotes a set of overloaded functions and/or
-function templates, 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* denotes the address of a set of overloaded
-functions and/or function templates, 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 1*: The resolution of the address of an overload set in other
 contexts is described in [[over.over]]. — *end note*]
 ##### Call to named function <a id="over.call.func">[[over.call.func]]</a>
@@ -199,82 +233,75 @@ 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
-Clause  [[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, Clause  [[over]] assumes that the
-*postfix-expression* that is the left operand of the `.` operator has
-type “cv `T`” where `T` denotes a class[^3]. 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 function calls ([[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` ([[class.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[^4]. 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.
 ##### Call to object of class type <a id="over.call.object">[[over.call.object]]</a>
-If the *primary-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
 ``` bnf
-'operator' conversion-type-id '( )' cv-qualifier ref-qualifierₒₚₜ noexcept-specifierₒₚₜ attribute-specifier-seqₒₚₜ ';'
 ```
-where *cv-qualifier* 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 (`P₁`, …, `Pₙ`) returning `R`”, or the type
-“reference to pointer to function of (`P₁`, …, `Pₙ`) returning `R`”, or
-the type “reference to function of (`P₁`, …, `Pₙ`) returning `R`”, a
-*surrogate call function* with the unique name *call-function* and
-having the form
 ``` bnf
-'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[^5].
-If such a surrogate call function is selected by overload resolution,
-the corresponding conversion function will be called to convert `E` to
-the appropriate function pointer or reference, and the function will
-then be invoked with the arguments of the call. If the conversion
-function cannot be called (e.g., because of an ambiguity), the program
-is ill-formed.
 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)`.
@@ -306,18 +333,18 @@ int i = a(1);                   // calls f1 via pointer returned from conversion
 #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
 If no operand of an operator in an expression has a type that is a class
 or an enumeration, the operator is assumed to be a built-in operator and
-interpreted according to Clause  [[expr]].
 [*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
-operators are always built-in operators interpreted according to Clause
-[[expr]]. `?:` cannot be overloaded, but the rules in this subclause are
-used to determine the conversions to be applied to the second and third
-operands when they have class or enumeration type (
-[[expr.cond]]). — *end note*]
 [*Example 1*:
 ``` cpp
 struct String {
@@ -326,11 +353,12 @@ struct String {
   operator const char* ();
 };
 String operator + (const String&, const String&);
 void f() {
- const char* p= "one" + "two"; // ill-formed because neither operand has class or enumeration type
   int I = 1 + 1;                // always evaluates to 2 even if class or enumeration types exist
                                 // that would perform the operation.
 }
 ```
@@ -341,16 +369,16 @@ user-defined operator function might be declared that implements this
 operator or a user-defined conversion can be necessary to convert the
 operand to a type that is appropriate for a built-in operator. In this
 case, overload resolution is used to determine which operator function
 or built-in operator is to be invoked to implement the operator.
 Therefore, the operator notation is first transformed to the equivalent
-function-call notation as summarized in Table  [[tab:over.rel.op.func]]
-(where `@` denotes one of the operators covered in the specified
-subclause). However, the operands are sequenced in the order prescribed
-for the built-in operator (Clause  [[expr]]).
-**Table: Relationship between operator and function call notation** <a id="tab:over.rel.op.func">[tab:over.rel.op.func]</a>
 | Subclause    | Expression | As member function  | As non-member function |
 | ------------ | ---------- | ------------------- | ---------------------- |
 | (a)}         |
 | (a, b)}      |
@@ -358,25 +386,24 @@ for the built-in operator (Clause  [[expr]]).
 | [[over.sub]] | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]] | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}      |
-For a unary operator `@` with an operand of a type whose cv-unqualified
-version is `T1`, and for a binary operator `@` with a left operand of a
-type whose cv-unqualified version is `T1` and a right operand of a type
-whose cv-unqualified version is `T2`, three sets of candidate functions,
-designated *member candidates*, *non-member candidates* and *built-in
-candidates*, are constructed as follows:
 - If `T1` is a complete class type or a class currently being defined,
   the set of member candidates is the result of the qualified lookup of
-  `T1::operator@` ([[over.call.func]]); otherwise, the set of member
   candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
-  the usual rules for name lookup in unqualified function calls (
-  [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   functions in the lookup set that have a first parameter of type `T1`
   or “reference to cv `T1`”, when `T1` is an enumeration type, or (if
   there is a right operand) a second parameter of type `T2` or
   “reference to cv `T2`”, when `T2` is an enumeration type, are
@@ -389,26 +416,48 @@ candidates*, are constructed as follows:
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
   - do not have the same parameter-type-list as any non-member candidate
     that is not a function template specialization.
 For the built-in assignment operators, conversions of the left operand
 are restricted as follows:
 - no temporaries are introduced to hold the left operand, and
 - no user-defined conversions are applied to the left operand to achieve
   a type match with the left-most parameter of a built-in candidate.
 For all other operators, no such restrictions apply.
-The set of candidate functions for overload resolution is the union of
-the member candidates, the non-member candidates, and the built-in
-candidates. The argument list contains all of the operands of the
-operator. The best function from the set of candidate functions is
-selected according to  [[over.match.viable]] and
-[[over.match.best]].[^6]
 [*Example 2*:
 ``` cpp
 struct A {
@@ -421,17 +470,36 @@ void m() {
 }
 ```
 — *end example*]
 If a built-in candidate is selected by overload resolution, the operands
 of class type are converted to the types of the corresponding parameters
 of the selected operation function, except that the second standard
-conversion sequence of a user-defined conversion sequence (
-[[over.ics.user]]) is not applied. Then the operator is treated as the
-corresponding built-in operator and interpreted according to Clause
-[[expr]].
 [*Example 3*:
 ``` cpp
 struct X {
@@ -453,14 +521,14 @@ The second operand of operator `->` is ignored in selecting an
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
 If the operator is the operator `,`, the unary operator `&`, or the
 operator `->`, and there are no viable functions, then the operator is
-assumed to be the built-in operator and interpreted according to Clause
-[[expr]].
-[*Note 2*:
 The lookup rules for operators in expressions are different than the
 lookup rules for operator function names in a function call, as shown in
 the following example:
@@ -483,19 +551,20 @@ void B::f() {
 — *end note*]
 #### Initialization by constructor <a id="over.match.ctor">[[over.match.ctor]]</a>
-When objects of class type are direct-initialized ([[dcl.init]]),
-copy-initialized from an expression of the same or a derived class
-type ([[dcl.init]]), or default-initialized ([[dcl.init]]), overload
-resolution selects the constructor. For direct-initialization or
 default-initialization that is not in the context of
 copy-initialization, the candidate functions are all the constructors of
-the class of the object being initialized. For copy-initialization, the
-candidate functions are all the converting constructors (
-[[class.conv.ctor]]) of that class. The argument list is the
 *expression-list* or *assignment-expression* of the *initializer*.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
@@ -509,25 +578,25 @@ to a possibly cv-qualified class type is determined in terms of a
 corresponding non-reference copy-initialization. — *end note*]
 Assuming that “*cv1* `T`” is the type of the object being initialized,
 with `T` a class type, the candidate functions are selected as follows:
-- The converting constructors ([[class.conv.ctor]]) of `T` are
- candidate functions.
 - When the type of the initializer expression is a class type “cv `S`”,
   the non-explicit conversion functions of `S` and its base classes are
-  considered. When initializing a temporary to be bound to the first
-  parameter of a constructor where the parameter is of type “reference
- to possibly cv-qualified `T`” and the constructor is called with a
   single argument in the context of direct-initialization of an object
-  of type “*cv2* `T`”, explicit conversion functions are also
   considered. Those that are not hidden within `S` and yield a type
   whose cv-unqualified version is the same type as `T` or is a derived
-  class thereof are candidate functions. Conversion functions that
- return “reference to `X`” return lvalues or xvalues, depending on the
- type of reference, of type `X` and are therefore considered to yield
- `X` for this process of selecting candidate functions.
 In both cases, the argument list has one argument, which is the
 initializer expression.
 [*Note 2*: This argument will be compared against the first parameter
@@ -546,120 +615,226 @@ the initializer expression, with `S` a class type, the candidate
 functions are selected as follows:
 - The conversion functions of `S` and its base classes are considered.
   Those non-explicit conversion functions that are not hidden within `S`
   and yield type `T` or a type that can be converted to type `T` via a
-  standard conversion sequence ([[over.ics.scs]]) are candidate
- functions. For direct-initialization, those explicit conversion
- functions that are not hidden within `S` and yield type `T` or a type
- that can be converted to type `T` with a qualification conversion (
- [[conv.qual]]) are also candidate functions. Conversion functions that
- return a cv-qualified type are considered to yield the cv-unqualified
- version of that type for this process of selecting candidate
- functions. Conversion functions that return “reference to *cv2* `X`”
- return lvalues or xvalues, depending on the type of reference, of type
- “*cv2* `X`” and are therefore considered to yield `X` for this process
-  of selecting candidate functions.
 The argument list has one argument, which is the initializer expression.
 [*Note 1*: This argument will be compared against the implicit object
 parameter of the conversion functions. — *end note*]
 #### Initialization by conversion function for direct reference binding <a id="over.match.ref">[[over.match.ref]]</a>
 Under the conditions specified in  [[dcl.init.ref]], a reference can be
-bound directly to a glvalue or class prvalue that is the result of
-applying a conversion function to an initializer expression. Overload
-resolution is used to select the conversion function to be invoked.
-Assuming that “reference to *cv1* `T`” is the type of the reference
-being initialized, and “cv `S`” is the type of the initializer
-expression, with `S` a class type, the candidate functions are selected
-as follows:
 - The conversion functions of `S` and its base classes are considered.
   Those non-explicit conversion functions that are not hidden within `S`
   and yield type “lvalue reference to *cv2* `T2`” (when initializing an
   lvalue reference or an rvalue reference to function) or “*cv2* `T2`”
   or “rvalue reference to *cv2* `T2`” (when initializing an rvalue
   reference or an lvalue reference to function), where “*cv1* `T`” is
-  reference-compatible ([[dcl.init.ref]]) with “*cv2* `T2`”, are
- candidate functions. For direct-initialization, those explicit
- conversion functions that are not hidden within `S` and yield type
- “lvalue reference to *cv2* `T2`” or “*cv2* `T2`” or “rvalue reference
- to *cv2* `T2`”, respectively, where `T2` is the same type as `T` or
- can be converted to type `T` with a qualification conversion (
- [[conv.qual]]), are also candidate functions.
 The argument list has one argument, which is the initializer expression.
 [*Note 1*: This argument will be compared against the implicit object
 parameter of the conversion functions. — *end note*]
 #### Initialization by list-initialization <a id="over.match.list">[[over.match.list]]</a>
 When objects of non-aggregate class type `T` are list-initialized such
 that [[dcl.init.list]] specifies that overload resolution is performed
-according to the rules in this section, overload resolution selects the
-constructor in two phases:
-- Initially, the candidate functions are the initializer-list
- constructors ([[dcl.init.list]]) of the class `T` and the argument
- list consists of the initializer list as a single argument.
-- If no viable initializer-list constructor is found, overload
- resolution is performed again, where the candidate functions are all
-  the constructors of the class `T` and the argument list consists of
- the elements of the initializer list.
-If the initializer list has no elements and `T` has a default
-constructor, the first phase is omitted. In copy-list-initialization, if
-an `explicit` constructor is chosen, the initialization is ill-formed.
-[*Note 1*: This differs from other situations ([[over.match.ctor]],
 [[over.match.copy]]), where only converting constructors are considered
 for copy-initialization. This restriction only applies if this
 initialization is part of the final result of overload
 resolution. — *end note*]
 #### Class template argument deduction <a id="over.match.class.deduct">[[over.match.class.deduct]]</a>
-A set of functions and function templates is formed comprising:
-- For each constructor of the primary class template designated by the
- *template-name*, if the template is defined, a function template with
-  the following properties:
-  - The template parameters are the template parameters of the class
- template followed by the template parameters (including default
-    template arguments) of the constructor, if any.
   - The types of the function parameters are those of the constructor.
   - The return type is the class template specialization designated by
- the *template-name* and template arguments corresponding to the
- template parameters obtained from the class template.
-- If the primary class template `C` is not defined or does not declare
- any constructors, an additional function template derived as above
- from a hypothetical constructor `C()`.
 - An additional function template derived as above from a hypothetical
   constructor `C(C)`, called the *copy deduction candidate*.
 - For each *deduction-guide*, a function or function template with the
   following properties:
   - The template parameters, if any, and function parameters are those
     of the *deduction-guide*.
   - The return type is the *simple-template-id* of the
     *deduction-guide*.
 Initialization and overload resolution are performed as described in
 [[dcl.init]] and [[over.match.ctor]], [[over.match.copy]], or
 [[over.match.list]] (as appropriate for the type of initialization
-performed) for an object of a hypothetical class type, where the
-selected functions and function templates are considered to be the
 constructors of that class type for the purpose of forming an overload
 set, and the initializer is provided by the context in which class
-template argument deduction was performed. Each such notional
-constructor is considered to be explicit if the function or function
-template was generated from a constructor or *deduction-guide* that was
-declared `explicit`. All such notional constructors are considered to be
-public members of the hypothetical class type.
 [*Example 1*:
 ``` cpp
 template <class T> struct A {
@@ -687,44 +862,163 @@ template <class T> struct B {
   template <class U> using TA = T;
   template <class U> B(U, TA<U>);
 };
 B b{(int*)0, (char*)0};         // OK, deduces B<char*>
 ```
 — *end example*]
 ### Viable functions <a id="over.match.viable">[[over.match.viable]]</a>
-From the set of candidate functions constructed for a given context (
-[[over.match.funcs]]), a set of viable functions is chosen, from which
 the best function will be selected by comparing argument conversion
-sequences for the best fit ([[over.match.best]]). The selection of
-viable functions considers relationships between arguments and function
-parameters other than the ranking of conversion sequences.
 First, to be a viable function, a candidate function shall have enough
 parameters to agree in number with the arguments in the list.
 - If there are *m* arguments in the list, all candidate functions having
   exactly *m* parameters are viable.
 - A candidate function having fewer than *m* parameters is viable only
-  if it has an ellipsis in its parameter list ([[dcl.fct]]). For the
   purposes of overload resolution, any argument for which there is no
-  corresponding parameter is considered to “match the ellipsis” (
-  [[over.ics.ellipsis]]) .
 - A candidate function having more than *m* parameters is viable only if
- the *(m+1)*-st parameter has a default argument (
-  [[dcl.fct.default]]).[^8] For the purposes of overload resolution, the
   parameter list is truncated on the right, so that there are exactly
   *m* parameters.
-Second, for `F` to be a viable function, there shall exist for each
-argument an *implicit conversion sequence* ([[over.best.ics]]) that
-converts that argument to the corresponding parameter of `F`. If the
-parameter has reference type, the implicit conversion sequence includes
-the operation of binding the reference, and the fact that an lvalue
 reference to non-`const` cannot be bound to an rvalue and that an rvalue
 reference cannot be bound to an lvalue can affect the viability of the
 function (see  [[over.ics.ref]]).
 ### Best viable function <a id="over.match.best">[[over.match.best]]</a>
@@ -732,11 +1026,11 @@ function (see  [[over.ics.ref]]).
 Define ICS*i*(`F`) as follows:
 - If `F` is a static member function, ICS*1*(`F`) is defined such that
   ICS*1*(`F`) is neither better nor worse than ICS*1*(`G`) for any
   function `G`, and, symmetrically, ICS*1*(`G`) is neither better nor
-  worse than ICS*1*(`F`);[^9] otherwise,
 - let ICS*i*(`F`) denote the implicit conversion sequence that converts
   the *i*-th argument in the list to the type of the *i*-th parameter of
   viable function `F`. [[over.best.ics]] defines the implicit conversion
   sequences and [[over.ics.rank]] defines what it means for one implicit
   conversion sequence to be a better conversion sequence or worse
@@ -769,14 +1063,14 @@ and then
   ```
   — *end example*]
   or, if not that,
 - the context is an initialization by conversion function for direct
-  reference binding ([[over.match.ref]]) of a reference to function
- type, the return type of `F1` is the same kind of reference (i.e.
- lvalue or rvalue) as the reference being initialized, and the return
- type of `F2` is not
   \[*Example 2*:
   ``` cpp
   template <class T> struct A {
     operator T&();    // #1
     operator T&&();   // #2
@@ -793,17 +1087,67 @@ and then
   template specialization, or, if not that,
 - `F1` and `F2` are function template specializations, and the function
   template for `F1` is more specialized than the template for `F2`
   according to the partial ordering rules described in
   [[temp.func.order]], or, if not that,
-- `F1` is generated from a *deduction-guide* (
- [[over.match.class.deduct]]) and `F2` is not, or, if not that,
-- `F1` is the copy deduction candidate ([[over.match.class.deduct]])
   and `F2` is not, or, if not that,
 - `F1` is generated from a non-template constructor and `F2` is
   generated from a constructor template.
-  \[*Example 3*:
   ``` cpp
   template <class T> struct A {
     using value_type = T;
     A(value_type);    // #1
     A(const A&);      // #2
@@ -829,13 +1173,13 @@ and then
   — *end example*]
 If there is exactly one viable function that is a better function than
 all other viable functions, then it is the one selected by overload
-resolution; otherwise the call is ill-formed.[^10]
-[*Example 4*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
@@ -860,11 +1204,11 @@ If the best viable function resolves to a function for which multiple
 declarations were found, and if at least two of these declarations — or
 the declarations they refer to in the case of *using-declaration*s —
 specify a default argument that made the function viable, the program is
 ill-formed.
-[*Example 5*:
 ``` cpp
 namespace A {
   extern "C" void f(int = 5);
 }
@@ -875,41 +1219,43 @@ namespace B {
 using A::f;
 using B::f;
 void use() {
   f(3);             // OK, default argument was not used for viability
-  f();              // Error: found default argument twice
 }
 ```
 — *end example*]
 #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
 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 Clause  [[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. Other
-properties, such as the lifetime, storage class, alignment,
-accessibility of the argument, whether the argument is a bit-field, and
-whether a function is deleted ([[dcl.fct.def.delete]]), 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.
 A well-formed implicit conversion sequence is one of the following
 forms:
-- a *standard conversion sequence* ([[over.ics.scs]]),
-- a *user-defined conversion sequence* ([[over.ics.user]]), or
-- an *ellipsis conversion sequence* ([[over.ics.ellipsis]]).
 However, if the target is
 - the first parameter of a constructor or
 - the implicit object parameter of a user-defined conversion function
@@ -926,25 +1272,25 @@ by
   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 1*: These rules prevent more than one user-defined conversion
 from being applied during overload resolution, thereby avoiding infinite
 recursion. — *end note*]
 [*Example 1*:
 ``` cpp
 struct Y { Y(int); };
 struct A { operator int(); };
 Y y1 = A();         // error: A::operator int() is not a candidate
- struct 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
@@ -954,12 +1300,12 @@ 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 2*: When the parameter has a class type, this is a conceptual
-conversion defined for the purposes of Clause  [[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.
@@ -971,39 +1317,39 @@ case is the identity sequence; it contains no “conversion” from
 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.
-[*Note 3*: There is no such standard conversion; this derived-to-base
-Conversion exists only in the description of implicit conversion
 sequences. — *end note*]
-A derived-to-base Conversion has Conversion rank ([[over.ics.scs]]).
 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.
 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 several different sequences of conversions exist that each convert
-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 4*:
 This rule prevents a function from becoming non-viable because of an
 ambiguous conversion sequence for one of its parameters.
 [*Example 3*:
@@ -1014,11 +1360,11 @@ class A { A (B&);};
 class B { operator A (); };
 class C { C (B&); };
 void f(A) { }
 void f(C) { }
 B b;
-f(b);               // ill-formed: 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
 ```
@@ -1033,69 +1379,66 @@ 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.
 ##### Standard conversion sequences <a id="over.ics.scs">[[over.ics.scs]]</a>
-Table  [[tab:over.conversions]] summarizes the conversions defined in
-Clause  [[conv]] and partitions them into four disjoint categories:
-Lvalue Transformation, Qualification Adjustment, Promotion, and
-Conversion.
-[*Note 5*: These categories are orthogonal with respect to value
 category, cv-qualification, and data representation: the Lvalue
 Transformations do not change the cv-qualification or data
 representation of the type; the Qualification Adjustments do not change
 the value category or data representation of the type; and the
 Promotions and Conversions do not change the value category or
 cv-qualification of the type. — *end note*]
-[*Note 6*: As described in Clause  [[conv]], a standard conversion
-sequence is either the Identity conversion by itself (that is, no
-conversion) or consists of one to three conversions from the other four
-categories. If there are two or more conversions in the sequence, the
-conversions are applied in the canonical order: **Lvalue
-Transformation**, **Promotion** or **Conversion**, **Qualification
-Adjustment**. — *end note*]
-Each conversion in Table  [[tab:over.conversions]] also has an
-associated rank (Exact Match, Promotion, or Conversion). These are used
-to rank standard conversion sequences ([[over.ics.rank]]). The rank of
-a conversion sequence is determined by considering the rank of each
-conversion in the sequence and the rank of any reference binding (
-[[over.ics.ref]]). If any of those has Conversion rank, the sequence has
-Conversion rank; otherwise, if any of those has Promotion rank, the
-sequence has Promotion rank; otherwise, the sequence has Exact Match
-rank.
-**Table: Conversions** <a id="tab:over.conversions">[tab:over.conversions]</a>
 | Conversion              | Category | Rank | Subclause         |
 | ----------------------- | -------- | ---- | ----------------- |
 | No conversions required | Identity |      |                   |
 | Integral promotions     |          |      | [[conv.prom]]     |
 | Integral conversions    |          |      | [[conv.integral]] |
 ##### User-defined conversion sequences <a id="over.ics.user">[[over.ics.user]]</a>
-A user-defined conversion sequence consists of an initial standard
-conversion sequence followed by a user-defined conversion (
-[[class.conv]]) followed by a second standard conversion sequence. If
-the user-defined conversion is specified by a constructor (
-[[class.conv.ctor]]), the initial standard conversion sequence converts
-the source type to the type required by the argument of the constructor.
-If the user-defined conversion is specified by a conversion function (
-[[class.conv.fct]]), the initial standard conversion sequence converts
-the source type to the implicit object parameter of the conversion
-function.
 The second standard conversion sequence converts the result of the
-user-defined conversion to the target type for the sequence. Since an
-implicit conversion sequence is an initialization, the special rules for
-initialization by user-defined conversion apply when selecting the best
-user-defined conversion for a user-defined conversion sequence (see
-[[over.match.best]] and  [[over.best.ics]]).
 If the user-defined conversion is specified by a specialization of a
 conversion function template, the second standard conversion sequence
 shall have exact match rank.
@@ -1111,15 +1454,15 @@ An ellipsis conversion sequence occurs when an argument in a function
 call is matched with the ellipsis parameter specification of the
 function called (see  [[expr.call]]).
 ##### Reference binding <a id="over.ics.ref">[[over.ics.ref]]</a>
-When a parameter of reference type binds directly ([[dcl.init.ref]]) to
-an argument expression, the implicit conversion sequence is the identity
 conversion, unless the argument expression has a type that is a derived
 class of the parameter type, in which case the implicit conversion
-sequence is a derived-to-base Conversion ([[over.best.ics]]).
 [*Example 4*:
 ``` cpp
 struct A {};
@@ -1131,73 +1474,108 @@ int i = f(b);       // calls f(B&), an exact match, rather than f(A&), a convers
 — *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]]), with the second
 standard conversion sequence either an identity conversion or, if the
 conversion function returns an entity of a type that is a derived class
-of the parameter type, a derived-to-base Conversion.
 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]]. Conceptually, this conversion sequence corresponds to
 copy-initializing a temporary of the referenced type with the argument
 expression. Any difference in top-level cv-qualification is subsumed by
 the initialization itself and does not constitute a conversion.
 Except for an implicit object parameter, for which see
-[[over.match.funcs]], a standard 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 other than a function lvalue.
-[*Note 7*: 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]]). — *end note*]
 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 a standard conversion sequence, however.
 [*Example 5*: A function with an “lvalue reference to `int`” parameter
 can be a viable candidate even if the corresponding argument is an `int`
 bit-field. The formation of implicit conversion sequences treats the
 `int` bit-field as an `int` lvalue and finds an exact match with the
 parameter. 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]]). — *end example*]
 ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
-When an argument is an initializer list ([[dcl.init.list]]), it is not
-an expression and special rules apply for converting it to a parameter
 type.
-If the parameter type is an aggregate class `X` and the initializer list
-has a single element of type cv `U`, where `U` is `X` or a class derived
-from `X`, the implicit conversion sequence is the one required to
-convert the element to the parameter type.
-Otherwise, if the parameter type is a character array [^11] and the
 initializer list has a single element that is an appropriately-typed
-string literal ([[dcl.init.string]]), the implicit conversion sequence
 is the identity conversion.
 Otherwise, if the parameter type is `std::initializer_list<X>` and all
 the elements of the initializer list can be implicitly converted to `X`,
 the implicit conversion sequence is the worst conversion necessary to
 convert an element of the list to `X`, or if the initializer list has no
 elements, the identity conversion. This conversion can be a user-defined
 conversion even in the context of a call to an initializer-list
 constructor.
-[*Example 6*:
 ``` cpp
 void f(std::initializer_list<int>);
 f( {} );                        // OK: f(initializer_list<int>) identity conversion
 f( {1,2,3} );                   // OK: f(initializer_list<int>) identity conversion
@@ -1219,15 +1597,16 @@ void h(const IA&);
 h({ 1, 2, 3 });                 // OK: identity conversion
 ```
 — *end example*]
-Otherwise, if the parameter type is “array of `N` `X`”, if there exists
-an implicit conversion sequence for each element of the array from the
-corresponding element of the initializer list (or from `{}` if there is
-no such element), the implicit conversion sequence is the worst such
-implicit conversion sequence.
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor
 `C` of `X` to perform the initialization of an object of type `X` from
 the argument initializer list:
@@ -1244,11 +1623,11 @@ If multiple constructors are viable but none is better than the others,
 the implicit conversion sequence is the ambiguous conversion sequence.
 User-defined conversions are allowed for conversion of the initializer
 list elements to the constructor parameter types except as noted in
 [[over.best.ics]].
-[*Example 7*:
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
@@ -1280,15 +1659,15 @@ i({ {1,2}, {"bar"} });  // OK: i(D(A(std::initializer_list<int>{1,2\), C(std::st
 — *end example*]
 Otherwise, if the parameter has an aggregate type which can be
 initialized from the initializer list according to the rules for
-aggregate initialization ([[dcl.init.aggr]]), the implicit conversion
 sequence is a user-defined conversion sequence with the second standard
 conversion sequence an identity conversion.
-[*Example 8*:
 ``` cpp
 struct A {
   int m1;
   double m2;
@@ -1301,14 +1680,14 @@ f( {1.0} );             // error: narrowing
 — *end example*]
 Otherwise, if the parameter is a reference, see  [[over.ics.ref]].
-[*Note 8*: The rules in this section will apply for initializing the
 underlying temporary for the reference. — *end note*]
-[*Example 9*:
 ``` cpp
 struct A {
   int m1;
   double m2;
@@ -1327,21 +1706,21 @@ g({1});                 // same conversion as int to double
 Otherwise, if the parameter type is not a class:
 - if the initializer list has one element that is not itself an
   initializer list, the implicit conversion sequence is the one required
   to convert the element to the parameter type;
-  \[*Example 10*:
   ``` cpp
   void f(int);
   f( {'a'} );             // OK: same conversion as char to int
   f( {1.0} );             // error: narrowing
   ```
   — *end example*]
 - if the initializer list has no elements, the implicit conversion
   sequence is the identity conversion.
-  \[*Example 11*:
   ``` cpp
   void f(int);
   f( { } );               // OK: identity conversion
   ```
@@ -1361,26 +1740,28 @@ sequence S1 is neither better than nor worse than conversion sequence
 S2, S1 and S2 are said to be *indistinguishable conversion sequences*.
 When comparing the basic forms of implicit conversion sequences (as
 defined in  [[over.best.ics]])
-- a standard conversion sequence ([[over.ics.scs]]) is a better
- conversion sequence than a user-defined conversion sequence or an
- ellipsis conversion sequence, and
-- a user-defined conversion sequence ([[over.ics.user]]) is a better
-  conversion sequence than an ellipsis conversion sequence (
-  [[over.ics.ellipsis]]).
 Two implicit conversion sequences of the same form are indistinguishable
 conversion sequences unless one of the following rules applies:
 - List-initialization sequence `L1` is a better conversion sequence than
   list-initialization sequence `L2` if
   - `L1` converts to `std::initializer_list<X>` for some `X` and `L2`
     does not, or, if not that,
-  - `L1` converts to type “array of `N1` `T`”, `L2` converts to type
- “array of `N2` `T`”, and `N1` is smaller than `N2`,
   even if one of the other rules in this paragraph would otherwise
   apply.
   \[*Example 1*:
   ``` cpp
@@ -1391,10 +1772,24 @@ conversion sequences unless one of the following rules applies:
   void f2(std::pair<const char*, const char*>);   // #3
   void f2(std::initializer_list<std::string>);    // #4
   void g2() { f2({"foo","bar"}); }                // chooses #4
   ```
   — *end example*]
 - Standard conversion sequence `S1` is a better conversion sequence than
   standard conversion sequence `S2` if
   - `S1` is a proper subsequence of `S2` (comparing the conversion
     sequences in the canonical form defined by  [[over.ics.scs]],
@@ -1402,15 +1797,15 @@ conversion sequences unless one of the following rules applies:
     sequence is considered to be a subsequence of any non-identity
     conversion sequence) or, if not that,
   - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
     have the same rank and are distinguishable by the rules in the
     paragraph below, or, if not that,
-  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and neither
-    refers to an implicit object parameter of a non-static member
-    function declared without a *ref-qualifier*, and `S1` binds an
-    rvalue reference to an rvalue and `S2` binds an lvalue reference
-    \[*Example 2*:
     ``` cpp
     int i;
     int f1();
     int&& f2();
     int g(const int&);
@@ -1434,45 +1829,43 @@ conversion sequences unless one of the following rules applies:
     a.p();                          // calls A::p()&
     ```
     — *end example*]
     or, if not that,
-  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and `S1`
     binds an lvalue reference to a function lvalue and `S2` binds an
     rvalue reference to a function lvalue
-    \[*Example 3*:
     ``` cpp
     int f(void(&)());               // #1
     int f(void(&&)());              // #2
     void g();
     int i1 = f(g);                  // calls #1
     ```
     — *end example*]
     or, if not that,
-  - `S1`
-    and `S2` differ only in their qualification conversion and yield
- similar types `T1` and `T2` ([[conv.qual]]), respectively, and the
- cv-qualification signature of type `T1` is a proper subset of the
-    cv-qualification signature of type `T2`
-    \[*Example 4*:
     ``` cpp
     int f(const volatile int *);
     int f(const int *);
     int i;
     int j = f(&i);                  // calls f(const int*)
     ```
     — *end example*]
     or, if not that,
   - `S1`
-    and `S2` are reference bindings ([[dcl.init.ref]]), and the types
     to which the references refer are the same type except for top-level
     cv-qualifiers, and the type to which the reference initialized by
     `S2` refers is more cv-qualified than the type to which the
     reference initialized by `S1` refers.
-    \[*Example 5*:
     ``` cpp
     int f(const int &);
     int f(int &);
     int g(const int &);
     int g(int);
@@ -1496,11 +1889,11 @@ conversion sequences unless one of the following rules applies:
   than another user-defined conversion sequence `U2` if they contain the
   same user-defined conversion function or constructor or they
   initialize the same class in an aggregate initialization and in either
   case the second standard conversion sequence of `U1` is better than
   the second standard conversion sequence of `U2`.
-  \[*Example 6*:
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
@@ -1514,12 +1907,12 @@ conversion sequences unless one of the following rules applies:
 Standard conversion sequences are ordered by their ranks: an Exact Match
 is a better conversion than a Promotion, which is a better conversion
 than a Conversion. Two conversion sequences with the same rank are
 indistinguishable unless one of the following rules applies:
-- A conversion that does not convert a pointer, a pointer to member, or
-  `std::nullptr_t` to `bool` is better than one that does.
 - A conversion that promotes an enumeration whose underlying type is
   fixed to its underlying type is better than one that promotes to the
   promoted underlying type, if the two are different.
 - If class `B` is derived directly or indirectly from class `A`,
   conversion of `B*` to `A*` is better than conversion of `B*` to
@@ -1527,11 +1920,11 @@ indistinguishable unless one of the following rules applies:
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
   class `C` is derived directly or indirectly from `B`,
   - conversion of `C*` to `B*` is better than conversion of `C*` to
     `A*`,
-    \[*Example 7*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;

 context ill-formed. — *end note*]
 Overload resolution selects the function to call in seven distinct
 contexts within the language:
+- invocation of a function named in the function call syntax
+  [[over.call.func]];
 - invocation of a function call operator, a pointer-to-function
   conversion function, a reference-to-pointer-to-function conversion
   function, or a reference-to-function conversion function on a class
+  object named in the function call syntax [[over.call.object]];
+- invocation of the operator referenced in an expression
+  [[over.match.oper]];
+- invocation of a constructor for default- or direct-initialization
+  [[dcl.init]] of a class object [[over.match.ctor]];
+- invocation of a user-defined conversion for copy-initialization
+  [[dcl.init]] of a class object [[over.match.copy]];
 - invocation of a conversion function for initialization of an object of
+  a non-class type from an expression of class type [[over.match.conv]];
+  and
+- invocation of a conversion function for conversion in which a
+  reference [[dcl.init.ref]] will be directly bound [[over.match.ref]].
 Each of these contexts defines the set of candidate functions and the
 list of arguments in its own unique way. But, once the candidate
 functions and argument lists have been identified, the selection of the
 best function is the same in all cases:
 - First, a subset of the candidate functions (those that have the proper
   number of arguments and meet certain other conditions) is selected to
+  form a set of viable functions [[over.match.viable]].
 - Then the best viable function is selected based on the implicit
+  conversion sequences [[over.best.ics]] needed to match each argument
+  to the corresponding parameter of each viable function.
 If a best viable function exists and is unique, overload resolution
 succeeds and produces it as the result. Otherwise overload resolution
 fails and the invocation is ill-formed. When overload resolution
+succeeds, and the best viable function is not accessible
+[[class.access]] in the context in which it is used, the program is
 ill-formed.
+Overload resolution results in a *usable candidate* if overload
+resolution succeeds and the selected candidate is either not a function
+[[over.built]], or is a function that is not deleted and is accessible
+from the context in which overload resolution was performed.
 ### Candidate functions and argument lists <a id="over.match.funcs">[[over.match.funcs]]</a>
 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. So that
 argument and parameter lists are comparable within this heterogeneous
+set, a member function 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. For the purposes of overload
 resolution, both static and non-static member functions have an implicit
 object parameter, but constructors do not.
 Similarly, when appropriate, the context can construct an argument list
+that contains an *implied object argument* as the first argument in the
+list to denote the object to be operated on.
 For non-static member functions, the type of the implicit object
 parameter is
 - “lvalue reference to cv `X`” for functions declared without a
 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 non-static 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
+[[over.ics.rank]]. — *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]]).
 class C : T {
 public:
   C(int);
 };
+T a = 1;            // error: no viable conversion (T(C(1)) not considered)
 ```
 — *end example*]
 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-specifier* whose
+*constant-expression* is value-dependent [[temp.dep]], template argument
+deduction is performed first and then, if the context requires a
+candidate that is 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.[^2] A given name can refer to one or more function templates and
+also to 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* `D` if the argument list has
+exactly one argument and `C` is reference-related to `P` and `P` is
+reference-related to `D`.
+[*Example 3*:
+``` cpp
+struct A {
+  A();                                  // #1
+  A(A &&);                              // #2
+  template<typename T> A(T &&);         // #3
+};
+struct B : A {
+  using A::A;
+  B(const B &);                         // #4
+  B(B &&) = default;                    // #5, implicitly deleted
+  struct X { X(X &&) = delete; } x;
+};
+extern B b1;
+B b2 = static_cast<B&&>(b1);            // calls #4: #1 is not viable, #2, #3, and #5 are not candidates
+struct C { operator B&&(); };
+B b3 = C();                             // calls #4
+```
+— *end example*]
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
+In a function call [[expr.call]]
 ``` bnf
 postfix-expression '(' expression-listₒₚₜ ')'
 ```
+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 1*: The resolution of the address of an overload set in other
 contexts is described in [[over.over]]. — *end note*]
 ##### Call to named function <a id="over.call.func">[[over.call.func]]</a>
 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.[^3] 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` [[class.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.[^4] 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.
 ##### Call to object of class type <a id="over.call.object">[[over.call.object]]</a>
+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
 ``` bnf
+operator conversion-type-id '( )' cv-qualifier-seqₒₚₜ ref-qualifierₒₚₜ noexcept-specifierₒₚₜ attribute-specifier-seqₒₚₜ ';'
 ```
+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 (`P₁`, …, `Pₙ`) returning `R`”,
+or the type “reference to pointer to function of (`P₁`, …, `Pₙ`)
+returning `R`”, or the type “reference to function of (`P₁`, …, `Pₙ`)
+returning `R`”, a *surrogate call function* with the unique name
+*call-function* and having the form
 ``` bnf
+'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.[^5]
 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)`.
 #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
 If no operand of an operator in an expression has a type that is a class
 or an enumeration, the operator is assumed to be a built-in operator and
+interpreted according to [[expr.compound]].
 [*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
+operators are always built-in operators interpreted according to
+[[expr.compound]]. `?:` cannot be overloaded, but the rules in this
+subclause are used to determine the conversions to be applied to the
+second and third operands when they have class or enumeration type
+[[expr.cond]]. — *end note*]
 [*Example 1*:
 ``` cpp
 struct String {
   operator const char* ();
 };
 String operator + (const String&, const String&);
 void f() {
+ const char* p= "one" + "two"; // error: cannot add two pointers; overloaded operator+ not considered
+                                // because neither operand has class or enumeration type
   int I = 1 + 1;                // always evaluates to 2 even if class or enumeration types exist
                                 // that would perform the operation.
 }
 ```
 operator or a user-defined conversion can be necessary to convert the
 operand to a type that is appropriate for a built-in operator. In this
 case, overload resolution is used to determine which operator function
 or built-in operator is to be invoked to implement the operator.
 Therefore, the operator notation is first transformed to the equivalent
+function-call notation as summarized in [[over.match.oper]] (where `@`
+denotes one of the operators covered in the specified subclause).
+However, the operands are sequenced in the order prescribed for the
+built-in operator [[expr.compound]].
+**Table: Relationship between operator and function call notation** <a id="over.match.oper">[over.match.oper]</a>
 | Subclause    | Expression | As member function  | As non-member function |
 | ------------ | ---------- | ------------------- | ---------------------- |
 | (a)}         |
 | (a, b)}      |
 | [[over.sub]] | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]] | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}      |
+For a unary operator `@` with an operand of type *cv1* `T1`, and for a
+binary operator `@` with a left operand of type *cv1* `T1` and a right
+operand of type *cv2* `T2`, four sets of candidate functions, designated
+*member candidates*, *non-member candidates*, *built-in candidates*, and
+*rewritten candidates*, are constructed as follows:
 - If `T1` is a complete class type or a class currently being defined,
   the set of member candidates is the result of the qualified lookup of
+  `T1::operator@` [[over.call.func]]; otherwise, the set of member
   candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
+  the usual rules for name lookup in unqualified function calls
+  [[basic.lookup.argdep]] except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   functions in the lookup set that have a first parameter of type `T1`
   or “reference to cv `T1`”, when `T1` is an enumeration type, or (if
   there is a right operand) a second parameter of type `T2` or
   “reference to cv `T2`”, when `T2` is an enumeration type, are
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
   - do not have the same parameter-type-list as any non-member candidate
     that is not a function template specialization.
+- The rewritten candidate set is determined as follows:
+  - For the relational [[expr.rel]] operators, the rewritten candidates
+    include all non-rewritten candidates for the expression `x <=> y`.
+  - For the relational [[expr.rel]] and three-way comparison
+    [[expr.spaceship]] operators, the rewritten candidates also include
+    a synthesized candidate, with the order of the two parameters
+    reversed, for each non-rewritten candidate for the expression
+    `y <=> x`.
+  - For the `!=` operator [[expr.eq]], the rewritten candidates include
+    all non-rewritten candidates for the expression `x == y`.
+  - For the equality operators, the rewritten candidates also include a
+    synthesized candidate, with the order of the two parameters
+    reversed, for each non-rewritten candidate for the expression
+    `y == x`.
+  - For all other operators, the rewritten candidate set is empty.
+  \[*Note 2*: A candidate synthesized from a member candidate has its
+  implicit object parameter as the second parameter, thus implicit
+  conversions are considered for the first, but not for the second,
+  parameter. — *end note*]
 For the built-in assignment operators, conversions of the left operand
 are restricted as follows:
 - no temporaries are introduced to hold the left operand, and
 - no user-defined conversions are applied to the left operand to achieve
   a type match with the left-most parameter of a built-in candidate.
 For all other operators, no such restrictions apply.
+The set of candidate functions for overload resolution for some operator
+`@` is the union of the member candidates, the non-member candidates,
+the built-in candidates, and the rewritten candidates for that operator
+`@`.
+The argument list contains all of the operands of the operator. The best
+function from the set of candidate functions is selected according to
+[[over.match.viable]] and  [[over.match.best]].[^6]
 [*Example 2*:
 ``` cpp
 struct A {
 }
 ```
 — *end example*]
+If a rewritten `operator<=>` candidate is selected by overload
+resolution for an operator `@`, `x @ y` is interpreted as
+`0 @ (y <=> x)` if the selected candidate is a synthesized candidate
+with reversed order of parameters, or `(x <=> y) @ 0` otherwise, using
+the selected rewritten `operator<=>` candidate. Rewritten candidates for
+the operator `@` are not considered in the context of the resulting
+expression.
+If a rewritten `operator==` candidate is selected by overload resolution
+for an operator `@`, its return type shall be cv `bool`, and `x @ y` is
+interpreted as:
+- if `@` is `!=` and the selected candidate is a synthesized candidate
+  with reversed order of parameters, `!(y == x)`,
+- otherwise, if `@` is `!=`, `!(x == y)`,
+- otherwise (when `@` is `==`), `y == x`,
+in each case using the selected rewritten `operator==` candidate.
 If a built-in candidate is selected by overload resolution, the operands
 of class type are converted to the types of the corresponding parameters
 of the selected operation function, except that the second standard
+conversion sequence of a user-defined conversion sequence
+[[over.ics.user]] is not applied. Then the operator is treated as the
+corresponding built-in operator and interpreted according to
+[[expr.compound]].
 [*Example 3*:
 ``` cpp
 struct X {
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
 If the operator is the operator `,`, the unary operator `&`, or the
 operator `->`, and there are no viable functions, then the operator is
+assumed to be the built-in operator and interpreted according to
+[[expr.compound]].
+[*Note 3*:
 The lookup rules for operators in expressions are different than the
 lookup rules for operator function names in a function call, as shown in
 the following example:
 — *end note*]
 #### Initialization by constructor <a id="over.match.ctor">[[over.match.ctor]]</a>
+When objects of class type are direct-initialized [[dcl.init]],
+copy-initialized from an expression of the same or a derived class type
+[[dcl.init]], or default-initialized [[dcl.init]], overload resolution
+selects the constructor. For direct-initialization or
 default-initialization that is not in the context of
 copy-initialization, the candidate functions are all the constructors of
+the class of the object being initialized. For copy-initialization
+(including default initialization in the context of
+copy-initialization), the candidate functions are all the converting
+constructors [[class.conv.ctor]] of that class. The argument list is the
 *expression-list* or *assignment-expression* of the *initializer*.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
 corresponding non-reference copy-initialization. — *end note*]
 Assuming that “*cv1* `T`” is the type of the object being initialized,
 with `T` a class type, the candidate functions are selected as follows:
+- The converting constructors [[class.conv.ctor]] of `T` are candidate
+  functions.
 - When the type of the initializer expression is a class type “cv `S`”,
   the non-explicit conversion functions of `S` and its base classes are
+  considered. When initializing a temporary object [[class.mem]] to be
+ bound to the first parameter of a constructor where the parameter is
+ of type “reference to *cv2* `T`” and the constructor is called with a
   single argument in the context of direct-initialization of an object
+  of type “*cv3* `T`”, explicit conversion functions are also
   considered. Those that are not hidden within `S` and yield a type
   whose cv-unqualified version is the same type as `T` or is a derived
+  class thereof are candidate functions. A call to a conversion function
+ returning “reference to `X`” is a glvalue of type `X`, and such a
+ conversion function is therefore considered to yield `X` for this
+  process of selecting candidate functions.
 In both cases, the argument list has one argument, which is the
 initializer expression.
 [*Note 2*: This argument will be compared against the first parameter
 functions are selected as follows:
 - The conversion functions of `S` and its base classes are considered.
   Those non-explicit conversion functions that are not hidden within `S`
   and yield type `T` or a type that can be converted to type `T` via a
+  standard conversion sequence [[over.ics.scs]] are candidate functions.
+  For direct-initialization, those explicit conversion functions that
+  are not hidden within `S` and yield type `T` or a type that can be
+  converted to type `T` with a qualification conversion [[conv.qual]]
+  are also candidate functions. Conversion functions that return a
+  cv-qualified type are considered to yield the cv-unqualified version
+  of that type for this process of selecting candidate functions. A call
+ to a conversion function returning “reference to `X`” is a glvalue of
+ type `X`, and such a conversion function is therefore considered to
+  yield `X` for this process of selecting candidate functions.
 The argument list has one argument, which is the initializer expression.
 [*Note 1*: This argument will be compared against the implicit object
 parameter of the conversion functions. — *end note*]
 #### Initialization by conversion function for direct reference binding <a id="over.match.ref">[[over.match.ref]]</a>
 Under the conditions specified in  [[dcl.init.ref]], a reference can be
+bound directly to the result of applying a conversion function to an
+initializer expression. Overload resolution is used to select the
+conversion function to be invoked. Assuming that “reference to *cv1*
+`T`” is the type of the reference being initialized, and “cv `S`” is the
+type of the initializer expression, with `S` a class type, the candidate
+functions are selected as follows:
 - The conversion functions of `S` and its base classes are considered.
   Those non-explicit conversion functions that are not hidden within `S`
   and yield type “lvalue reference to *cv2* `T2`” (when initializing an
   lvalue reference or an rvalue reference to function) or “*cv2* `T2`”
   or “rvalue reference to *cv2* `T2`” (when initializing an rvalue
   reference or an lvalue reference to function), where “*cv1* `T`” is
+  reference-compatible [[dcl.init.ref]] with “*cv2* `T2`”, are candidate
+  functions. For direct-initialization, those explicit conversion
+  functions that are not hidden within `S` and yield type “lvalue
+  reference to *cv2* `T2`” (when initializing an lvalue reference or an
+ rvalue reference to function) or “rvalue reference to *cv2* `T2`”
+ (when initializing an rvalue reference or an lvalue reference to
+ function), where `T2` is the same type as `T` or can be converted to
+  type `T` with a qualification conversion [[conv.qual]], are also
+  candidate functions.
 The argument list has one argument, which is the initializer expression.
 [*Note 1*: This argument will be compared against the implicit object
 parameter of the conversion functions. — *end note*]
 #### Initialization by list-initialization <a id="over.match.list">[[over.match.list]]</a>
 When objects of non-aggregate class type `T` are list-initialized such
 that [[dcl.init.list]] specifies that overload resolution is performed
+according to the rules in this subclause or when forming a
+list-initialization sequence according to [[over.ics.list]], overload
+resolution selects the constructor in two phases:
+- If the initializer list is not empty or `T` has no default
+ constructor, overload resolution is first performed where the
+ candidate functions are the initializer-list constructors
+  [[dcl.init.list]] of the class `T` and the argument list consists of
+ the initializer list as a single argument.
+- Otherwise, or if no viable initializer-list constructor is found,
+ overload resolution is performed again, where the candidate functions
+  are all the constructors of the class `T` and the argument list
+  consists of the elements of the initializer list.
+In copy-list-initialization, if an explicit constructor is chosen, the
+initialization is ill-formed.
+[*Note 1*: This differs from other situations ([[over.match.ctor]],
 [[over.match.copy]]), where only converting constructors are considered
 for copy-initialization. This restriction only applies if this
 initialization is part of the final result of overload
 resolution. — *end note*]
 #### Class template argument deduction <a id="over.match.class.deduct">[[over.match.class.deduct]]</a>
+When resolving a placeholder for a deduced class type
+[[dcl.type.class.deduct]] where the *template-name* names a primary
+class template `C`, a set of functions and function templates, called
+the guides of `C`, is formed comprising:
+- If `C` is defined, for each constructor of `C`, a function template
+ with the following properties:
+ - The template parameters are the template parameters of `C` followed
+    by the template parameters (including default template arguments) of
+    the constructor, if any.
   - The types of the function parameters are those of the constructor.
   - The return type is the class template specialization designated by
+ `C` and template arguments corresponding to the template parameters
+ of `C`.
+- If `C` is not defined or does not declare any constructors, an
+  additional function template derived as above from a hypothetical
+  constructor `C()`.
 - An additional function template derived as above from a hypothetical
   constructor `C(C)`, called the *copy deduction candidate*.
 - For each *deduction-guide*, a function or function template with the
   following properties:
   - The template parameters, if any, and function parameters are those
     of the *deduction-guide*.
   - The return type is the *simple-template-id* of the
     *deduction-guide*.
+In addition, if `C` is defined and its definition satisfies the
+conditions for an aggregate class [[dcl.init.aggr]] with the assumption
+that any dependent base class has no virtual functions and no virtual
+base classes, and the initializer is a non-empty *braced-init-list* or
+parenthesized *expression-list*, and there are no *deduction-guide*s for
+`C`, the set contains an additional function template, called the
+*aggregate deduction candidate*, defined as follows. Let x₁, …, xₙ be
+the elements of the *initializer-list* or *designated-initializer-list*
+of the *braced-init-list*, or of the *expression-list*. For each xᵢ, let
+eᵢ be the corresponding aggregate element of `C` or of one of its
+(possibly recursive) subaggregates that would be initialized by xᵢ
+[[dcl.init.aggr]] if
+- brace elision is not considered for any aggregate element that has a
+  dependent non-array type or an array type with a value-dependent
+  bound, and
+- each non-trailing aggregate element that is a pack expansion is
+  assumed to correspond to no elements of the initializer list, and
+- a trailing aggregate element that is a pack expansion is assumed to
+  correspond to all remaining elements of the initializer list (if any).
+If there is no such aggregate element eᵢ for any xᵢ, the aggregate
+deduction candidate is not added to the set. The aggregate deduction
+candidate is derived as above from a hypothetical constructor
+`C`(`T₁`, …, `Tₙ`), where
+- if eᵢ is of array type and xᵢ is a *braced-init-list* or
+  *string-literal*, `Tᵢ` is an rvalue reference to the declared type of
+  eᵢ, and
+- otherwise, `Tᵢ` is the declared type of eᵢ,
+except that additional parameter packs of the form `Pⱼ` `...` are
+inserted into the parameter list in their original aggregate element
+position corresponding to each non-trailing aggregate element of type
+`Pⱼ` that was skipped because it was a parameter pack, and the trailing
+sequence of parameters corresponding to a trailing aggregate element
+that is a pack expansion (if any) is replaced by a single parameter of
+the form `Tₙ` `...`.
+When resolving a placeholder for a deduced class type
+[[dcl.type.simple]] where the *template-name* names an alias template
+`A`, the *defining-type-id* of `A` must be of the form
+``` bnf
+typenameₒₚₜ nested-name-specifierₒₚₜ templateₒₚₜ simple-template-id
+```
+as specified in [[dcl.type.simple]]. The guides of `A` are the set of
+functions or function templates formed as follows. For each function or
+function template `f` in the guides of the template named by the
+*simple-template-id* of the *defining-type-id*, the template arguments
+of the return type of `f` are deduced from the *defining-type-id* of `A`
+according to the process in [[temp.deduct.type]] with the exception that
+deduction does not fail if not all template arguments are deduced. Let
+`g` denote the result of substituting these deductions into `f`. If
+substitution succeeds, form a function or function template `f'` with
+the following properties and add it to the set of guides of `A`:
+- The function type of `f'` is the function type of `g`.
+- If `f` is a function template, `f'` is a function template whose
+  template parameter list consists of all the template parameters of `A`
+  (including their default template arguments) that appear in the above
+  deductions or (recursively) in their default template arguments,
+  followed by the template parameters of `f` that were not deduced
+  (including their default template arguments), otherwise `f'` is not a
+  function template.
+- The associated constraints [[temp.constr.decl]] are the conjunction of
+  the associated constraints of `g` and a constraint that is satisfied
+  if and only if the arguments of `A` are deducible (see below) from the
+  return type.
+- If `f` is a copy deduction candidate [[over.match.class.deduct]], then
+  `f'` is considered to be so as well.
+- If `f` was generated from a *deduction-guide*
+  [[over.match.class.deduct]], then `f'` is considered to be so as well.
+- The *explicit-specifier* of `f'` is the *explicit-specifier* of `g`
+  (if any).
+The arguments of a template `A` are said to be deducible from a type `T`
+if, given a class template
+``` cpp
+template <typename> class AA;
+```
+with a single partial specialization whose template parameter list is
+that of `A` and whose template argument list is a specialization of `A`
+with the template argument list of `A` [[temp.dep.type]], `AA<T>`
+matches the partial specialization.
 Initialization and overload resolution are performed as described in
 [[dcl.init]] and [[over.match.ctor]], [[over.match.copy]], or
 [[over.match.list]] (as appropriate for the type of initialization
+performed) for an object of a hypothetical class type, where the guides
+of the template named by the placeholder are considered to be the
 constructors of that class type for the purpose of forming an overload
 set, and the initializer is provided by the context in which class
+template argument deduction was performed. The following exceptions
+apply:
+- The first phase in [[over.match.list]] (considering initializer-list
+  constructors) is omitted if the initializer list consists of a single
+  expression of type cv `U`, where `U` is, or is derived from, a
+  specialization of the class template directly or indirectly named by
+  the placeholder.
+- During template argument deduction for the aggregate deduction
+  candidate, the number of elements in a trailing parameter pack is only
+  deduced from the number of remaining function arguments if it is not
+  otherwise deduced.
+If the function or function template was generated from a constructor or
+*deduction-guide* that had an *explicit-specifier*, each such notional
+constructor is considered to have that same *explicit-specifier*. All
+such notional constructors are considered to be public members of the
+hypothetical class type.
 [*Example 1*:
 ``` cpp
 template <class T> struct A {
   template <class U> using TA = T;
   template <class U> B(U, TA<U>);
 };
 B b{(int*)0, (char*)0};         // OK, deduces B<char*>
+template <typename T>
+struct S {
+  T x;
+  T y;
+};
+template <typename T>
+struct C {
+  S<T> s;
+  T t;
+};
+template <typename T>
+struct D {
+  S<int> s;
+  T t;
+};
+C c1 = {1, 2};                  // error: deduction failed
+C c2 = {1, 2, 3};               // error: deduction failed
+C c3 = {{1u, 2u}, 3};           // OK, deduces C<int>
+D d1 = {1, 2};                  // error: deduction failed
+D d2 = {1, 2, 3};               // OK, braces elided, deduces D<int>
+template <typename T>
+struct E {
+  T t;
+  decltype(t) t2;
+};
+E e1 = {1, 2};                  // OK, deduces E<int>
+template <typename... T>
+struct Types {};
+template <typename... T>
+struct F : Types<T...>, T... {};
+struct X {};
+struct Y {};
+struct Z {};
+struct W { operator Y(); };
+F f1 = {Types<X, Y, Z>{}, {}, {}};      // OK, F<X, Y, Z> deduced
+F f2 = {Types<X, Y, Z>{}, X{}, Y{}};    // OK, F<X, Y, Z> deduced
+F f3 = {Types<X, Y, Z>{}, X{}, W{}};    // error: conflicting types deduced; operator Y not considered
+```
+— *end example*]
+[*Example 2*:
+``` cpp
+template <class T, class U> struct C {
+  C(T, U);                                      // #1
+};
+template<class T, class U>
+  C(T, U) -> C<T, std::type_identity_t<U>>;     // #2
+template<class V> using A = C<V *, V *>;
+template<std::integral W> using B = A<W>;
+int i{};
+double d{};
+A a1(&i, &i);   // deduces A<int>
+A a2(i, i);     // error: cannot deduce V * from i
+A a3(&i, &d);   // error: #1: cannot deduce (V*, V*) from (int *, double *)
+                // #2: cannot deduce A<V> from C<int *, double *>
+B b1(&i, &i);   // deduces B<int>
+B b2(&d, &d);   // error: cannot deduce B<W> from C<double *, double *>
+```
+Possible exposition-only implementation of the above procedure:
+``` cpp
+// The following concept ensures a specialization of A is deduced.
+template <class> class AA;
+template <class V> class AA<A<V>> { };
+template <class T> concept deduces_A = requires { sizeof(AA<T>); };
+// f1 is formed from the constructor #1 of C, generating the following function template
+template<T, U>
+  auto f1(T, U) -> C<T, U>;
+// Deducing arguments for C<T, U> from C<V *, V*> deduces T as V * and U as V *;
+// f1' is obtained by transforming f1 as described by the above procedure.
+template<class V> requires deduces_A<C<V *, V *>>
+  auto f1_prime(V *, V*) -> C<V *, V *>;
+// f2 is formed from the deduction-guide #2 of C
+template<class T, class U> auto f2(T, U) -> C<T, std::type_identity_t<U>>;
+// Deducing arguments for C<T, std::type_identity_t<U>> from C<V *, V*> deduces T as V *;
+// f2' is obtained by transforming f2 as described by the above procedure.
+template<class V, class U>
+  requires deduces_A<C<V *, std::type_identity_t<U>>>
+  auto f2_prime(V *, U) -> C<V *, std::type_identity_t<U>>;
+// The following concept ensures a specialization of B is deduced.
+template <class> class BB;
+template <class V> class BB<B<V>> { };
+template <class T> concept deduces_B = requires { sizeof(BB<T>); };
+// The guides for B derived from the above f1' and f2' for A are as follows:
+template<std::integral W>
+  requires deduces_A<C<W *, W *>> && deduces_B<C<W *, W *>>
+  auto f1_prime_for_B(W *, W *) -> C<W *, W *>;
+template<std::integral W, class U>
+  requires deduces_A<C<W *, std::type_identity_t<U>>> &&
+    deduces_B<C<W *, std::type_identity_t<U>>>
+  auto f2_prime_for_B(W *, U) -> C<W *, std::type_identity_t<U>>;
 ```
 — *end example*]
 ### Viable functions <a id="over.match.viable">[[over.match.viable]]</a>
+From the set of candidate functions constructed for a given context
+[[over.match.funcs]], a set of viable functions is chosen, from which
 the best function will be selected by comparing argument conversion
+sequences and associated constraints [[temp.constr.decl]] for the best
+fit [[over.match.best]]. The selection of viable functions considers
+associated constraints, if any, and relationships between arguments and
+function parameters other than the ranking of conversion sequences.
 First, to be a viable function, a candidate function shall have enough
 parameters to agree in number with the arguments in the list.
 - If there are *m* arguments in the list, all candidate functions having
   exactly *m* parameters are viable.
 - A candidate function having fewer than *m* parameters is viable only
+  if it has an ellipsis in its parameter list [[dcl.fct]]. For the
   purposes of overload resolution, any argument for which there is no
+  corresponding parameter is considered to “match the ellipsis”
+  [[over.ics.ellipsis]] .
 - A candidate function having more than *m* parameters is viable only if
+ all parameters following the mᵗʰ have default arguments
+  [[dcl.fct.default]]. For the purposes of overload resolution, the
   parameter list is truncated on the right, so that there are exactly
   *m* parameters.
+Second, for a function to be viable, if it has associated constraints
+[[temp.constr.decl]], those constraints shall be satisfied
+[[temp.constr.constr]].
+Third, for `F` to be a viable function, there shall exist for each
+argument an implicit conversion sequence [[over.best.ics]] that converts
+that argument to the corresponding parameter of `F`. If the parameter
+has reference type, the implicit conversion sequence includes the
+operation of binding the reference, and the fact that an lvalue
 reference to non-`const` cannot be bound to an rvalue and that an rvalue
 reference cannot be bound to an lvalue can affect the viability of the
 function (see  [[over.ics.ref]]).
 ### Best viable function <a id="over.match.best">[[over.match.best]]</a>
 Define ICS*i*(`F`) as follows:
 - If `F` is a static member function, ICS*1*(`F`) is defined such that
   ICS*1*(`F`) is neither better nor worse than ICS*1*(`G`) for any
   function `G`, and, symmetrically, ICS*1*(`G`) is neither better nor
+  worse than ICS*1*(`F`);[^8] otherwise,
 - let ICS*i*(`F`) denote the implicit conversion sequence that converts
   the *i*-th argument in the list to the type of the *i*-th parameter of
   viable function `F`. [[over.best.ics]] defines the implicit conversion
   sequences and [[over.ics.rank]] defines what it means for one implicit
   conversion sequence to be a better conversion sequence or worse
   ```
   — *end example*]
   or, if not that,
 - the context is an initialization by conversion function for direct
+  reference binding [[over.match.ref]] of a reference to function type,
+  the return type of `F1` is the same kind of reference (lvalue or
+  rvalue) as the reference being initialized, and the return type of
+  `F2` is not
   \[*Example 2*:
   ``` cpp
   template <class T> struct A {
     operator T&();    // #1
     operator T&&();   // #2
   template specialization, or, if not that,
 - `F1` and `F2` are function template specializations, and the function
   template for `F1` is more specialized than the template for `F2`
   according to the partial ordering rules described in
   [[temp.func.order]], or, if not that,
+- `F1` and `F2` are non-template functions with the same
+ parameter-type-lists, and `F1` is more constrained than `F2` according
+  to the partial ordering of constraints described in
+  [[temp.constr.order]], or if not that,
+- `F1` is a constructor for a class `D`, `F2` is a constructor for a
+  base class `B` of `D`, and for all arguments the corresponding
+  parameters of `F1` and `F2` have the same type.
+  \[*Example 3*:
+  ``` cpp
+  struct A {
+    A(int = 0);
+  };
+  struct B: A {
+    using A::A;
+    B();
+  };
+  int main() {
+    B b;              // OK, B::B()
+  }
+  ```
+  — *end example*]
+  or, if not that,
+- `F2` is a rewritten candidate [[over.match.oper]] and `F1` is not
+  \[*Example 4*:
+  ``` cpp
+  struct S {
+    friend auto operator<=>(const S&, const S&) = default;        // #1
+    friend bool operator<(const S&, const S&);                    // #2
+  };
+  bool b = S() < S();                                             // calls #2
+  ```
+  — *end example*]
+  or, if not that,
+- `F1` and `F2` are rewritten candidates, and `F2` is a synthesized
+  candidate with reversed order of parameters and `F1` is not
+  \[*Example 5*:
+  ``` cpp
+  struct S {
+    friend std::weak_ordering operator<=>(const S&, int);         // #1
+    friend std::weak_ordering operator<=>(int, const S&);         // #2
+  };
+  bool b = 1 < S();                                               // calls #2
+  ```
+  — *end example*]
+  or, if not that
+- `F1` is generated from a *deduction-guide* [[over.match.class.deduct]]
   and `F2` is not, or, if not that,
+- `F1` is the copy deduction candidate [[over.match.class.deduct]] and
+  `F2` is not, or, if not that,
 - `F1` is generated from a non-template constructor and `F2` is
   generated from a constructor template.
+  \[*Example 6*:
   ``` cpp
   template <class T> struct A {
     using value_type = T;
     A(value_type);    // #1
     A(const A&);      // #2
   — *end example*]
 If there is exactly one viable function that is a better function than
 all other viable functions, then it is the one selected by overload
+resolution; otherwise the call is ill-formed.[^9]
+[*Example 7*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
 declarations were found, and if at least two of these declarations — or
 the declarations they refer to in the case of *using-declaration*s —
 specify a default argument that made the function viable, the program is
 ill-formed.
+[*Example 8*:
 ``` cpp
 namespace A {
   extern "C" void f(int = 5);
 }
 using A::f;
 using B::f;
 void use() {
   f(3);             // OK, default argument was not used for viability
+  f();              // error: found default argument twice
 }
 ```
 — *end example*]
 #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
 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 class,
+alignment, accessibility of the argument, whether the argument is a
+bit-field, and whether a function is deleted [[dcl.fct.def.delete]], 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:
+- a standard conversion sequence [[over.ics.scs]],
+- a user-defined conversion sequence [[over.ics.user]], or
+- an ellipsis conversion sequence [[over.ics.ellipsis]].
 However, if the target is
 - the first parameter of a constructor or
 - the implicit object parameter of a user-defined conversion function
   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*:
 ``` cpp
 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
 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.
 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.
+[*Note 4*: There is no such standard conversion; this derived-to-base
+conversion exists only in the description of implicit conversion
 sequences. — *end note*]
+A derived-to-base conversion has Conversion rank [[over.ics.scs]].
 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.
 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 5*:
 This rule prevents a function from becoming non-viable because of an
 ambiguous conversion sequence for one of its parameters.
 [*Example 3*:
 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
 ```
 The three forms of implicit conversion sequences mentioned above are
 defined in the following subclauses.
 ##### Standard conversion sequences <a id="over.ics.scs">[[over.ics.scs]]</a>
+summarizes the conversions defined in [[conv]] and partitions them into
+four disjoint categories: Lvalue Transformation, Qualification
+Adjustment, Promotion, and Conversion.
+[*Note 6*: These categories are orthogonal with respect to value
 category, cv-qualification, and data representation: the Lvalue
 Transformations do not change the cv-qualification or data
 representation of the type; the Qualification Adjustments do not change
 the value category or data representation of the type; and the
 Promotions and Conversions do not change the value category or
 cv-qualification of the type. — *end note*]
+[*Note 7*: As described in [[conv]], a standard conversion sequence
+either is the Identity conversion by itself (that is, no conversion) or
+consists of one to three conversions from the other four categories. If
+there are two or more conversions in the sequence, the conversions are
+applied in the canonical order: **Lvalue Transformation**, **Promotion**
+or **Conversion**, **Qualification Adjustment**. — *end note*]
+Each conversion in [[over.ics.scs]] also has an associated rank (Exact
+Match, Promotion, or Conversion). These are used to rank standard
+conversion sequences [[over.ics.rank]]. The rank of a conversion
+sequence is determined by considering the rank of each conversion in the
+sequence and the rank of any reference binding [[over.ics.ref]]. If any
+of those has Conversion rank, the sequence has Conversion rank;
+otherwise, if any of those has Promotion rank, the sequence has
+Promotion rank; otherwise, the sequence has Exact Match rank.
+**Table: Conversions** <a id="over.ics.scs">[over.ics.scs]</a>
 | Conversion              | Category | Rank | Subclause         |
 | ----------------------- | -------- | ---- | ----------------- |
 | No conversions required | Identity |      |                   |
 | Integral promotions     |          |      | [[conv.prom]]     |
 | Integral conversions    |          |      | [[conv.integral]] |
 ##### User-defined conversion sequences <a id="over.ics.user">[[over.ics.user]]</a>
+A *user-defined conversion sequence* consists of an initial standard
+conversion sequence followed by a user-defined conversion [[class.conv]]
+followed by a second standard conversion sequence. If the user-defined
+conversion is specified by a constructor [[class.conv.ctor]], the
+initial standard conversion sequence converts the source type to the
+type required by the argument of the constructor. If the user-defined
+conversion is specified by a conversion function [[class.conv.fct]], the
+initial standard conversion sequence converts the source type to the
+implicit object parameter of the conversion function.
 The second standard conversion sequence converts the result of the
+user-defined conversion to the target type for the sequence; any
+reference binding is included in the second standard conversion
+sequence. Since an implicit conversion sequence is an initialization,
+the special rules for initialization by user-defined conversion apply
+when selecting the best user-defined conversion for a user-defined
+conversion sequence (see  [[over.match.best]] and  [[over.best.ics]]).
 If the user-defined conversion is specified by a specialization of a
 conversion function template, the second standard conversion sequence
 shall have exact match rank.
 call is matched with the ellipsis parameter specification of the
 function called (see  [[expr.call]]).
 ##### Reference binding <a id="over.ics.ref">[[over.ics.ref]]</a>
+When a parameter of reference type binds directly [[dcl.init.ref]] to an
+argument expression, the implicit conversion sequence is the identity
 conversion, unless the argument expression has a type that is a derived
 class of the parameter type, in which case the implicit conversion
+sequence is a derived-to-base Conversion [[over.best.ics]].
 [*Example 4*:
 ``` cpp
 struct A {};
 — *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]], with the second
 standard conversion sequence either an identity conversion or, if the
 conversion function returns an entity of a type that is a derived class
+of the parameter type, a derived-to-base conversion.
 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]]. Conceptually, this conversion sequence corresponds to
 copy-initializing a temporary of the referenced type with the argument
 expression. Any difference in top-level cv-qualification is subsumed by
 the initialization itself and does not constitute a conversion.
 Except for an implicit object parameter, for which see
+[[over.match.funcs]], 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 other than a function lvalue.
+[*Note 8*: 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]]). — *end note*]
 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.
 [*Example 5*: A function with an “lvalue reference to `int`” parameter
 can be a viable candidate even if the corresponding argument is an `int`
 bit-field. The formation of implicit conversion sequences treats the
 `int` bit-field as an `int` lvalue and finds an exact match with the
 parameter. 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]]. — *end example*]
 ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
+When an argument is an initializer list [[dcl.init.list]], it is not an
+expression and special rules apply for converting it to a parameter
 type.
+If the initializer list is a *designated-initializer-list*, a conversion
+is only possible if the parameter has an aggregate type that can be
+initialized from the initializer list according to the rules for
+aggregate initialization [[dcl.init.aggr]], in which case the implicit
+conversion sequence is a user-defined conversion sequence whose second
+standard conversion sequence is an identity conversion.
+[*Note 9*:
+Aggregate initialization does not require that the members are declared
+in designation order. If, after overload resolution, the order does not
+match for the selected overload, the initialization of the parameter
+will be ill-formed [[dcl.init.list]].
+[*Example 6*:
+``` cpp
+struct A { int x, y; };
+struct B { int y, x; };
+void f(A a, int);               // #1
+void f(B b, ...);               // #2
+void g(A a);                    // #3
+void g(B b);                    // #4
+void h() {
+  f({.x = 1, .y = 2}, 0);       // OK; calls #1
+  f({.y = 2, .x = 1}, 0);       // error: selects #1, initialization of a fails
+                                // due to non-matching member order[dcl.init.list]
+  g({.x = 1, .y = 2});          // error: ambiguous between #3 and #4
+}
+```
+— *end example*]
+— *end note*]
+Otherwise, if the parameter type is an aggregate class `X` and the
+initializer list has a single element of type cv `U`, where `U` is `X`
+or a class derived from `X`, the implicit conversion sequence is the one
+required to convert the element to the parameter type.
+Otherwise, if the parameter type is a character array [^10] and the
 initializer list has a single element that is an appropriately-typed
+*string-literal* [[dcl.init.string]], the implicit conversion sequence
 is the identity conversion.
 Otherwise, if the parameter type is `std::initializer_list<X>` and all
 the elements of the initializer list can be implicitly converted to `X`,
 the implicit conversion sequence is the worst conversion necessary to
 convert an element of the list to `X`, or if the initializer list has no
 elements, the identity conversion. This conversion can be a user-defined
 conversion even in the context of a call to an initializer-list
 constructor.
+[*Example 7*:
 ``` cpp
 void f(std::initializer_list<int>);
 f( {} );                        // OK: f(initializer_list<int>) identity conversion
 f( {1,2,3} );                   // OK: f(initializer_list<int>) identity conversion
 h({ 1, 2, 3 });                 // OK: identity conversion
 ```
 — *end example*]
+Otherwise, if the parameter type is “array of `N` `X`” or “array of
+unknown bound of `X`”, if there exists an implicit conversion sequence
+from each element of the initializer list (and from `{}` in the former
+case if `N` exceeds the number of elements in the initializer list) to
+`X`, the implicit conversion sequence is the worst such implicit
+conversion sequence.
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor
 `C` of `X` to perform the initialization of an object of type `X` from
 the argument initializer list:
 the implicit conversion sequence is the ambiguous conversion sequence.
 User-defined conversions are allowed for conversion of the initializer
 list elements to the constructor parameter types except as noted in
 [[over.best.ics]].
+[*Example 8*:
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
 — *end example*]
 Otherwise, if the parameter has an aggregate type which can be
 initialized from the initializer list according to the rules for
+aggregate initialization [[dcl.init.aggr]], the implicit conversion
 sequence is a user-defined conversion sequence with the second standard
 conversion sequence an identity conversion.
+[*Example 9*:
 ``` cpp
 struct A {
   int m1;
   double m2;
 — *end example*]
 Otherwise, if the parameter is a reference, see  [[over.ics.ref]].
+[*Note 10*: The rules in this subclause will apply for initializing the
 underlying temporary for the reference. — *end note*]
+[*Example 10*:
 ``` cpp
 struct A {
   int m1;
   double m2;
 Otherwise, if the parameter type is not a class:
 - if the initializer list has one element that is not itself an
   initializer list, the implicit conversion sequence is the one required
   to convert the element to the parameter type;
+  \[*Example 11*:
   ``` cpp
   void f(int);
   f( {'a'} );             // OK: same conversion as char to int
   f( {1.0} );             // error: narrowing
   ```
   — *end example*]
 - if the initializer list has no elements, the implicit conversion
   sequence is the identity conversion.
+  \[*Example 12*:
   ``` cpp
   void f(int);
   f( { } );               // OK: identity conversion
   ```
 S2, S1 and S2 are said to be *indistinguishable conversion sequences*.
 When comparing the basic forms of implicit conversion sequences (as
 defined in  [[over.best.ics]])
+- a standard conversion sequence [[over.ics.scs]] is a better conversion
+  sequence than a user-defined conversion sequence or an ellipsis
+  conversion sequence, and
+- a user-defined conversion sequence [[over.ics.user]] is a better
+  conversion sequence than an ellipsis conversion sequence
+  [[over.ics.ellipsis]].
 Two implicit conversion sequences of the same form are indistinguishable
 conversion sequences unless one of the following rules applies:
 - List-initialization sequence `L1` is a better conversion sequence than
   list-initialization sequence `L2` if
   - `L1` converts to `std::initializer_list<X>` for some `X` and `L2`
     does not, or, if not that,
+  - `L1` and `L2` convert to arrays of the same element type, and either
+ the number of elements n₁ initialized by `L1` is less than the
+    number of elements n₂ initialized by `L2`, or n₁ = n₂ and `L2`
+    converts to an array of unknown bound and `L1` does not,
   even if one of the other rules in this paragraph would otherwise
   apply.
   \[*Example 1*:
   ``` cpp
   void f2(std::pair<const char*, const char*>);   // #3
   void f2(std::initializer_list<std::string>);    // #4
   void g2() { f2({"foo","bar"}); }                // chooses #4
   ```
+  — *end example*]
+  \[*Example 2*:
+  ``` cpp
+  void f(int    (&&)[] );         // #1
+  void f(double (&&)[] );         // #2
+  void f(int    (&&)[2]);         // #3
+  f( {1} );           // Calls #1: Better than #2 due to conversion, better than #3 due to bounds
+  f( {1.0} );         // Calls #2: Identity conversion is better than floating-integral conversion
+  f( {1.0, 2.0} );    // Calls #2: Identity conversion is better than floating-integral conversion
+  f( {1, 2} );        // Calls #3: Converting to array of known bound is better than to unknown bound,
+                      // and an identity conversion is better than floating-integral conversion
+  ```
   — *end example*]
 - Standard conversion sequence `S1` is a better conversion sequence than
   standard conversion sequence `S2` if
   - `S1` is a proper subsequence of `S2` (comparing the conversion
     sequences in the canonical form defined by  [[over.ics.scs]],
     sequence is considered to be a subsequence of any non-identity
     conversion sequence) or, if not that,
   - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
     have the same rank and are distinguishable by the rules in the
     paragraph below, or, if not that,
+  - `S1` and `S2` include reference bindings [[dcl.init.ref]] and
+ neither refers to an implicit object parameter of a non-static
+ member function declared without a *ref-qualifier*, and `S1` binds
+ an rvalue reference to an rvalue and `S2` binds an lvalue reference
+    \[*Example 3*:
     ``` cpp
     int i;
     int f1();
     int&& f2();
     int g(const int&);
     a.p();                          // calls A::p()&
     ```
     — *end example*]
     or, if not that,
+  - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
     binds an lvalue reference to a function lvalue and `S2` binds an
     rvalue reference to a function lvalue
+    \[*Example 4*:
     ``` cpp
     int f(void(&)());               // #1
     int f(void(&&)());              // #2
     void g();
     int i1 = f(g);                  // calls #1
     ```
     — *end example*]
     or, if not that,
+  - `S1` and `S2` differ only in their qualification conversion
+ [[conv.qual]] and yield similar types `T1` and `T2`, respectively,
+ where `T1` can be converted to `T2` by a qualification conversion.
+ \[*Example 5*:
     ``` cpp
     int f(const volatile int *);
     int f(const int *);
     int i;
     int j = f(&i);                  // calls f(const int*)
     ```
     — *end example*]
     or, if not that,
   - `S1`
+    and `S2` include reference bindings [[dcl.init.ref]], and the types
     to which the references refer are the same type except for top-level
     cv-qualifiers, and the type to which the reference initialized by
     `S2` refers is more cv-qualified than the type to which the
     reference initialized by `S1` refers.
+    \[*Example 6*:
     ``` cpp
     int f(const int &);
     int f(int &);
     int g(const int &);
     int g(int);
   than another user-defined conversion sequence `U2` if they contain the
   same user-defined conversion function or constructor or they
   initialize the same class in an aggregate initialization and in either
   case the second standard conversion sequence of `U1` is better than
   the second standard conversion sequence of `U2`.
+  \[*Example 7*:
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
 Standard conversion sequences are ordered by their ranks: an Exact Match
 is a better conversion than a Promotion, which is a better conversion
 than a Conversion. Two conversion sequences with the same rank are
 indistinguishable unless one of the following rules applies:
+- A conversion that does not convert a pointer or a pointer to member to
+  `bool` is better than one that does.
 - A conversion that promotes an enumeration whose underlying type is
   fixed to its underlying type is better than one that promotes to the
   promoted underlying type, if the two are different.
 - If class `B` is derived directly or indirectly from class `A`,
   conversion of `B*` to `A*` is better than conversion of `B*` to
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
   class `C` is derived directly or indirectly from `B`,
   - conversion of `C*` to `B*` is better than conversion of `C*` to
     `A*`,
+    \[*Example 8*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;

Diff to HTML by rtfpessoa