[over.match] - C++23 → Trunk

Files changed (1) hide show

tmp/tmp8xz9bthj/{from.md → to.md} +312 -179

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

@@ -94,12 +94,12 @@ parameter is
 - “lvalue reference to cv `X`” for functions declared without a
   *ref-qualifier* or with the `&` *ref-qualifier*
 - “rvalue reference to cv `X`” for functions declared with the `&&`
   *ref-qualifier*
-where `X` is the class of which the function is a member and cv is the
-cv-qualification on the member function declaration.
 [*Example 1*: For a `const` member function of class `X`, the extra
 parameter is assumed to have type “lvalue reference to
 `const X`”. — *end example*]
@@ -251,63 +251,80 @@ If the function selected by overload resolution is an implicit object
 member function, the program is ill-formed.
 [*Note 2*: 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>
 Of interest in  [[over.call.func]] are only those function calls in
-which the *postfix-expression* ultimately contains an *id-expression*
-that denotes one or more functions. Such a *postfix-expression*, perhaps
-nested arbitrarily deep in parentheses, has one of the following forms:
 ``` bnf
 postfix-expression:
     postfix-expression '.' id-expression
     postfix-expression '->' id-expression
- primary-expression
 ```
 These represent two syntactic subcategories of function calls: qualified
 function calls and unqualified function calls.
-In qualified function calls, the function is named by an *id-expression*
-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.[^2]
-The function declarations found by name lookup [[class.member.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 function is named by a
-*primary-expression*. The function declarations found by name lookup
-[[basic.lookup]] constitute the set of candidate functions. Because of
-the rules for name lookup, the set of candidate functions consists
-either entirely of non-member functions or entirely of member functions
-of some class `T`. In the former case or if the *primary-expression* is
-the address of an overload set, the argument list is the same as the
-*expression-list* in the call. Otherwise, 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 current class
-is, or is derived from, `T`, and the keyword `this` [[expr.prim.this]]
-refers to it, then the implied object argument is `(*this)`. Otherwise,
-a contrived object of type `T` becomes the implied object argument;[^3]
-if overload resolution selects a non-static member function, the call is
-ill-formed.
 [*Example 1*:
 ``` cpp
 struct C {
- void a();
   void b() {
     a();                // OK, (*this).a()
   }
   void c(this const C&);    // #1
@@ -340,10 +357,19 @@ void d() {
   void k(this int);
   operator int() const;
   void m(this const C& c) {
     c.k();              // OK
   }
 };
 ```
 — *end example*]
@@ -370,11 +396,11 @@ 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`
@@ -453,14 +479,14 @@ 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.ass]] | `a=b`      | `(a).operator= (b)` |                        |
 | [[over.sub]]    | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]]    | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}         |
@@ -557,16 +583,12 @@ inline namespace N {
 bool d1 = 0 == D();             // OK, calls reversed #4; #5 does not forbid #4 as a rewrite target
 ```
 — *end example*]
-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,
@@ -675,17 +697,18 @@ void B::f() {
 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
 copy-initialization of an object of class type, a user-defined
@@ -698,11 +721,11 @@ 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`”,
   conversion functions are considered. The permissible types for
   non-explicit conversion functions are `T` and any class derived from
   `T`. When initializing a temporary object [[class.mem]] to be bound to
@@ -749,14 +772,13 @@ 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, the candidate
 functions are selected as follows:
 - Let R be a set of types including
-  - “lvalue reference to *cv2* `T2`” (when initializing an lvalue
-    reference or an rvalue reference to function) and
-  - “*cv2* `T2`” and “rvalue reference to *cv2* `T2`” (when initializing
-    an rvalue reference or an lvalue reference to function)
   for any `T2`. The permissible types for non-explicit conversion
   functions are the members of R where “*cv1* `T`” is
   reference-compatible [[dcl.init.ref]] with “*cv2* `T2`”. For
   direct-initialization, the permissible types for explicit conversion
@@ -789,40 +811,47 @@ resolution selects the constructor in two phases:
 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
@@ -882,11 +911,11 @@ 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]] having a member typedef `type`
 designating a template specialization with the template argument list of
 `A` but with `C` as the template.
-[*Note 1*: Equivalently, the template parameter list of the
 specialization is that of `C`, the template argument list of the
 specialization is `B`, and the member typedef names `C` with the
 template argument list of `C`. — *end note*]
 [*Example 1*:
@@ -939,12 +968,13 @@ J j = { "ghi" };    // error: cannot bind reference to array of unsigned char to
 ```
 — *end example*]
 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
 ```
@@ -1184,15 +1214,76 @@ parameters to agree in number with the arguments in the list.
 - 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]].
@@ -1223,14 +1314,14 @@ then
 - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
   ICSʲ(`F₂`), or, if not that,
 - the context is an initialization by user-defined conversion (see
   [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
-  standard conversion sequence from the return type of `F₁` to the
   destination type (i.e., the type of the entity being initialized) is a
   better conversion sequence than the standard conversion sequence from
-  the return type of `F₂` to the destination type
   \[*Example 1*:
   ``` cpp
   struct A {
     A();
     operator int();
@@ -1244,13 +1335,13 @@ 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 (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
@@ -1261,24 +1352,38 @@ then
   Fn&& rf = a;        // calls #2
   ```
   — *end example*]
   or, if not that,
-- `F1` is not a function template specialization and `F2` is a function
   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);
   };
@@ -1292,48 +1397,48 @@ then
   }
   ```
   — *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` and `F2` are generated from class template argument deduction
-  [[over.match.class.deduct]] for a class `D`, and `F2` is generated
-  from inheriting constructors from a base class of `D` while `F1` is
   not, and for each explicit function argument, the corresponding
-  parameters of `F1` and `F2` are either both ellipses or have the same
   type, 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
@@ -1361,11 +1466,11 @@ then
 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.[^7]
-[*Example 7*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
@@ -1384,35 +1489,13 @@ void f() {
 }
 ```
 — *end example*]
-If the best viable function resolves to a function for which multiple
-declarations were found, and if any two of these declarations inhabit
-different scopes and 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);
-}
-namespace B {
-  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>
 ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
@@ -1425,17 +1508,17 @@ 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]],
@@ -1492,40 +1575,40 @@ parameter.
 [*Note 3*: When the parameter has a class type, this is a conceptual
 conversion defined for the purposes of [[over]]; the actual
 initialization is defined in terms of constructors and is not a
 conversion. — *end note*]
-Any difference in top-level cv-qualification is subsumed by the
-initialization itself and does not constitute a conversion.
-[*Example 2*: A parameter of type `A` can be initialized from an
-argument of type `const A`. The implicit conversion sequence for that
-case is the identity sequence; it contains no “conversion” from
-`const A` to `A`. — *end example*]
-When the parameter has a class type and the argument expression has the
-same type, the implicit conversion sequence is an identity conversion.
-When the parameter has a class type and the argument expression has a
-derived class type, the implicit conversion sequence is a
-derived-to-base conversion from the derived class to the base class. A
-derived-to-base conversion has Conversion rank [[over.ics.scs]].
 [*Note 4*: There is no such standard conversion; this derived-to-base
 conversion exists only in the description of implicit conversion
 sequences. — *end note*]
 When the parameter is the implicit object parameter of a static member
 function, the implicit conversion sequence is a standard conversion
 sequence that is neither better nor worse than any other standard
 conversion sequence.
 In all contexts, when converting to the implicit object parameter or
 when converting to the left operand of an assignment operation only
 standard conversion sequences are allowed.
-[*Note 5*: When converting to the explicit object parameter, if any,
-user-defined conversion sequences are allowed. — *end note*]
 If no conversions are required to match an argument to a parameter type,
 the implicit conversion sequence is the standard conversion sequence
 consisting of the identity conversion [[over.ics.scs]].
@@ -1632,11 +1715,11 @@ 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.
 A conversion of an expression of class type to the same class type is
 given Exact Match rank, and a conversion of an expression of class type
 to a base class of that type is given Conversion rank, in spite of the
 fact that a constructor (i.e., a user-defined conversion function) is
@@ -1648,34 +1731,47 @@ 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 {};
 struct B : public A {} b;
 int f(A&);
 int f(B&);
 int i = f(b);       // calls f(B&), an exact match, rather than f(A&), a conversion
 ```
 — *end example*]
 If the parameter binds directly to the result of applying a conversion
 function to the argument expression, the implicit conversion sequence is
 a user-defined conversion sequence [[over.ics.user]] whose second
-standard conversion sequence is 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
@@ -1685,11 +1781,11 @@ 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 9*: 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
@@ -1712,16 +1808,17 @@ non-`const` lvalue reference to a bit-field
 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 10*:
 Aggregate initialization does not require that the members are declared
 in designation order. If, after overload resolution, the order does not
@@ -1777,11 +1874,11 @@ f( {1,2,3} );                   // OK, f(initializer_list<int>) identity convers
 f( {'a','b'} );                 // OK, f(initializer_list<int>) integral promotion
 f( {1.0} );                     // error: narrowing
 struct A {
   A(std::initializer_list<double>);                     // #1
-  A(std::initializer_list<complex<double>>); // #2
   A(std::initializer_list<std::string>);                // #3
 };
 A a{ 1.0,2.0 };                 // OK, uses #1
 void g(A);
@@ -2025,12 +2122,12 @@ conversion sequences unless one of the following rules applies:
     ```
     — *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();
@@ -2038,28 +2135,33 @@ conversion sequences unless one of the following rules applies:
     ```
     — *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 &);
@@ -2075,20 +2177,51 @@ conversion sequences unless one of the following rules applies:
     };
     void g(const X& a, X b) {
       a.f();                        // calls X::f() const
       b.f();                        // calls X::f()
     }
     ```
     — *end example*]
 - User-defined conversion sequence `U1` is a better conversion sequence
   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);
@@ -2116,11 +2249,11 @@ indistinguishable unless one of the following rules applies:
     to the rank of `FP2`, and
   - `T3` is not a floating-point type, or `T3` is a floating-point type
     whose rank is not equal to the rank of `FP1`, or the floating-point
     conversion subrank [[conv.rank]] of `FP2` is greater than the
     subrank of `T3`.
-    \[*Example 8*:
     ``` cpp
     int f(std::float32_t);
     int f(std::float64_t);
     int f(long long);
     float x;
@@ -2137,11 +2270,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 9*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;

 - “lvalue reference to cv `X`” for functions declared without a
   *ref-qualifier* or with the `&` *ref-qualifier*
 - “rvalue reference to cv `X`” for functions declared with the `&&`
   *ref-qualifier*
+where `X` is the class of which the function is a direct member and cv
+is the cv-qualification on the member function declaration.
 [*Example 1*: For a `const` member function of class `X`, the extra
 parameter is assumed to have type “lvalue reference to
 `const X`”. — *end example*]
 member function, the program is ill-formed.
 [*Note 2*: The resolution of the address of an overload set in other
 contexts is described in [[over.over]]. — *end note*]
+##### Call to designated function <a id="over.call.func">[[over.call.func]]</a>
 Of interest in  [[over.call.func]] are only those function calls in
+which the *postfix-expression* ultimately contains an *id-expression* or
+*splice-expression* that designates one or more functions. Such a
+*postfix-expression*, perhaps nested arbitrarily deep in parentheses,
+has one of the following forms:
 ``` bnf
 postfix-expression:
     postfix-expression '.' id-expression
+    postfix-expression '.' splice-expression
     postfix-expression '->' id-expression
+ postfix-expression '->' splice-expression
+    id-expression
+    splice-expression
 ```
 These represent two syntactic subcategories of function calls: qualified
 function calls and unqualified function calls.
+In qualified function calls, the function is designated by an
+*id-expression* or *splice-expression* E 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.[^2]
+The set of candidate functions either is the set found by name lookup
+[[class.member.lookup]] if E is an *id-expression* or is the set
+determined as specified in  [[expr.prim.splice]] if E is a
+*splice-expression*. 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 function is designated by an
+*id-expression* or a *splice-expression* E. The set of candidate
+functions either is the set found by name lookup [[basic.lookup]] if E
+is an *id-expression* or is the set determined as specified in
+[[expr.prim.splice]] if E is a *splice-expression*. The set of candidate
+functions consists either entirely of non-member functions or entirely
+of member functions of some class `T`. In the former case or if E is
+either a *splice-expression* or the address of an overload set, the
+argument list is the same as the *expression-list* in the call.
+Otherwise, 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 current class is, or is derived from,
+`T`, and the keyword `this` [[expr.prim.this]] refers to it,
+- if the unqualified function call appears in a precondition assertion
+  of a constructor or a postcondition assertion of a destructor and
+  overload resolution selects a non-static member function, the call is
+  ill-formed;
+- otherwise, the implied object argument is `(*this)`.
+Otherwise,
+- if overload resolution selects a non-static member function, the call
+  is ill-formed;
+- otherwise, a contrived object of type `T` becomes the implied object
+  argument.[^3]
 [*Example 1*:
 ``` cpp
 struct C {
+ bool a();
   void b() {
     a();                // OK, (*this).a()
   }
   void c(this const C&);    // #1
   void k(this int);
   operator int() const;
   void m(this const C& c) {
     c.k();              // OK
   }
+  C()
+    pre(a())            // error: implied this in constructor precondition
+    pre(this->a())      // OK
+    post(a());          // OK
+  ~C()
+    pre(a())            // OK
+    post(a())           // error: implied this in destructor postcondition
+    post(this->a());    // OK
 };
 ```
 — *end example*]
 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`
 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.assign]] | `a=b`      | `(a).operator= (b)` |                        |
 | [[over.sub]]    | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]]    | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}         |
 bool d1 = 0 == D();             // OK, calls reversed #4; #5 does not forbid #4 as a rewrite target
 ```
 — *end example*]
+For the first parameter of the built-in assignment operators, only
+standard conversion sequences [[over.ics.scs]] are considered.
 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,
 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 (including default-initialization in the context
+of copy-list-initialization), the candidate functions are all the
+constructors of the class of the object being initialized. Otherwise,
+the candidate functions are all the non-explicit constructors
+[[class.conv.ctor]] of that class. The argument list is the
+*expression-list* or *assignment-expression* of the *initializer*. For
+default-initialization in the context of copy-list-initialization, if an
+explicit constructor is chosen, the initialization is ill-formed.
 #### 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
 copy-initialization of an object of class type, a user-defined
 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 non-explicit constructors [[class.conv.ctor]] of `T` are candidate
   functions.
 - When the type of the initializer expression is a class type “cv `S`”,
   conversion functions are considered. The permissible types for
   non-explicit conversion functions are `T` and any class derived from
   `T`. When initializing a temporary object [[class.mem]] to be bound to
 conversion function to be invoked. Assuming that “reference to *cv1*
 `T`” is the type of the reference being initialized, the candidate
 functions are selected as follows:
 - Let R be a set of types including
+  - “lvalue reference to *cv2* `T2`” (when converting to an lvalue) and
+  - “*cv2* `T2`” and “rvalue reference to *cv2* `T2`” (when converting
+    to an rvalue or an lvalue of function type)
   for any `T2`. The permissible types for non-explicit conversion
   functions are the members of R where “*cv1* `T`” is
   reference-compatible [[dcl.init.ref]] with “*cv2* `T2`”. For
   direct-initialization, the permissible types for explicit conversion
 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 non-explicit
 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* or
+*splice-type-specifier* designates 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 associated constraints [[temp.constr.decl]] are the conjunction
+    of the associated constraints of `C` and the associated constraints
+    of the constructor, if any. \[*Note 1*: A *constraint-expression* in
+    the *template-head* of `C` is checked for satisfaction before any
+    constraints from the *template-head* or trailing *requires-clause*
+    of the constructor. — *end note*]
+  - The *parameter-declaration-clause* is that 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-head*, if any, and *parameter-declaration-clause* 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
 template argument list is a specialization of `A` with the template
 argument list of `A` [[temp.dep.type]] having a member typedef `type`
 designating a template specialization with the template argument list of
 `A` but with `C` as the template.
+[*Note 2*: Equivalently, the template parameter list of the
 specialization is that of `C`, the template argument list of the
 specialization is `B`, and the member typedef names `C` with the
 template argument list of `C`. — *end note*]
 [*Example 1*:
 ```
 — *end example*]
 When resolving a placeholder for a deduced class type
+[[dcl.type.simple]] where the *template-name* or *splice-type-specifier*
+designates an alias template `A`, the *defining-type-id* of `A` must be
+of the form
 ``` bnf
 typenameₒₚₜ nested-name-specifierₒₚₜ templateₒₚₜ simple-template-id
 ```
 - 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 `C` having more than m parameters is viable only
+ if the set of scopes G, as defined below, is not empty. G consists of
+ every scope X that satisfies all of the following:
+ - There is a declaration of `C`, whose host scope is X, considered by
+    the overload resolution.
+  - For every $k^\textrm{th}$ parameter P where k \> m, there is a
+    reachable declaration, whose host scope is X, that specifies a
+    default argument [[dcl.fct.default]] for P.
+  If `C` is selected as the best viable function [[over.match.best]]:
+  - G shall contain exactly one scope (call it S).
+  - If the candidates are denoted by a *splice-expression*, then S shall
+    not be a block scope.
+  - The default arguments used in the call to `C` are the default
+    arguments specified by the reachable declarations whose host scope
+    is S.
+  For the purposes of overload resolution, the parameter list is
+  truncated on the right, so that there are exactly m parameters.
+[*Example 1*:
+``` cpp
+namespace A {
+  extern "C" void f(int, int = 5);
+  extern "C" void f(int = 6, int);
+}
+namespace B {
+  extern "C" void f(int, int = 7);
+}
+void use() {
+  [:^^A::f:](3, 4);     // OK, default argument was not used for viability
+  [:^^A::f:](3);        // error: default argument provided by declarations from two scopes
+  [:^^A::f:]();         // OK, default arguments provided by declarations in the scope of A
+  using A::f;
+  using B::f;
+  f(3, 4);              // OK, default argument was not used for viability
+  f(3);                 // error: default argument provided by declaration from two scopes
+  f();                  // OK, default arguments provided by declarations in the scope of A
+  void g(int = 8);
+  g();                  // OK
+  [:^^g:]();            // error: host scope is block scope
+}
+void h(int = 7);
+constexpr std::meta::info r = ^^h;
+void poison() {
+  void h(int = 8);
+  h();                  // OK, calls h(8)
+  [:^^h:]();            // error: default argument provided by declarations from two scopes
+}
+void call_h() {
+  [:^^h:]();            // error: default argument provided by declarations from two scopes
+  [:r:]();              // error: default argument provided by declarations from two scopes
+}
+template<typename... Ts>
+int k(int = 3, Ts...);
+int i = k<int>();       // error: no default argument for the second parameter
+int j = k<>();          // OK
+```
+— *end example*]
 Second, for a function to be viable, if it has associated constraints
 [[temp.constr.decl]], those constraints shall be satisfied
 [[temp.constr.constr]].
 - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
   ICSʲ(`F₂`), or, if not that,
 - the context is an initialization by user-defined conversion (see
   [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
+  standard conversion sequence from the result of `F₁` to the
   destination type (i.e., the type of the entity being initialized) is a
   better conversion sequence than the standard conversion sequence from
+  the result of `F₂` to the destination type
   \[*Example 1*:
   ``` cpp
   struct A {
     A();
     operator int();
   — *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 `F₁` is the same kind of reference (lvalue or
   rvalue) as the reference being initialized, and the return type of
+  `F₂` is not
   \[*Example 2*:
   ``` cpp
   template <class T> struct A {
     operator T&();    // #1
     operator T&&();   // #2
   Fn&& rf = a;        // calls #2
   ```
   — *end example*]
   or, if not that,
+- `F₁` is not a function template specialization and `F₂` is a function
   template specialization, or, if not that,
+- `F₁` and `F₂` are function template specializations, and the function
+  template for `F₁` is more specialized than the template for `F₂`
   according to the partial ordering rules described in
   [[temp.func.order]], or, if not that,
+- `F₁` and `F₂` are non-template functions and `F₁` is more
+ partial-ordering-constrained than `F₂` [[temp.constr.order]]
+ \[*Example 3*:
+ ``` cpp
+  template <typename T = int>
+  struct S {
+    constexpr void f();                       // #1
+    constexpr void f(this S&) requires true;  // #2
+  };
+  void test() {
+    S<> s;
+    s.f();                // calls #2
+  }
+  ```
+  — *end example*]
+  or, if not that,
+- `F₁` is a constructor for a class `D`, `F₂` is a constructor for a
   base class `B` of `D`, and for all arguments the corresponding
+  parameters of `F₁` and `F₂` have the same type
+  \[*Example 4*:
   ``` cpp
   struct A {
     A(int = 0);
   };
   }
   ```
   — *end example*]
   or, if not that,
+- `F₂` is a rewritten candidate [[over.match.oper]] and `F₁` is not
+  \[*Example 5*:
   ``` 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,
+- `F₁` and `F₂` are rewritten candidates, and `F₂` is a synthesized
+  candidate with reversed order of parameters and `F₁` is not
+  \[*Example 6*:
   ``` 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,
+- `F₁` and `F₂` are generated from class template argument deduction
+  [[over.match.class.deduct]] for a class `D`, and `F₂` is generated
+  from inheriting constructors from a base class of `D` while `F₁` is
   not, and for each explicit function argument, the corresponding
+  parameters of `F₁` and `F₂` are either both ellipses or have the same
   type, or, if not that,
+- `F₁` is generated from a *deduction-guide* [[over.match.class.deduct]]
+  and `F₂` is not, or, if not that,
+- `F₁` is the copy deduction candidate [[over.match.class.deduct]] and
+  `F₂` is not, or, if not that,
+- `F₁` is generated from a non-template constructor and `F₂` is
   generated from a constructor template.
+  \[*Example 7*:
   ``` cpp
   template <class T> struct A {
     using value_type = T;
     A(value_type);    // #1
     A(const A&);      // #2
 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.[^7]
+[*Example 8*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
 }
 ```
 — *end example*]
+[*Note 1*: If the best viable function was made viable by one or more
+default arguments, additional requirements apply
+[[over.match.viable]]. — *end note*]
 #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
 ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
 Implicit conversion sequences are concerned only with the type,
 cv-qualification, and value category of the argument and how these are
 converted to match the corresponding properties of the parameter.
+[*Note 1*: Other properties, such as the lifetime, storage duration,
+linkage, alignment, accessibility of the argument, whether the argument
+is a bit-field, and whether a function is deleted
+[[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]],
 [*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*]
+When the cv-unqualified version of the type of the argument expression
+is the same as the parameter type, the implicit conversion sequence is
+an identity conversion. When the parameter has a class type and the
+argument expression has a (possibly cv-qualified) derived class type,
+the implicit conversion sequence is a derived-to-base conversion from
+the derived class to the base class. A derived-to-base conversion has
+Conversion rank [[over.ics.scs]].
 [*Note 4*: There is no such standard conversion; this derived-to-base
 conversion exists only in the description of implicit conversion
 sequences. — *end note*]
+[*Example 2*: An implicit conversion sequence from an argument of type
+`const A` to a parameter of type `A` can be formed, even if overload
+resolution for copy-initialization of `A` from the argument would not
+find a viable function [[over.match.ctor]], [[over.match.viable]]. The
+implicit conversion sequence for that case is the identity sequence; it
+contains no “conversion” from `const A` to `A`. — *end example*]
 When the parameter is the implicit object parameter of a static member
 function, the implicit conversion sequence is a standard conversion
 sequence that is neither better nor worse than any other standard
 conversion sequence.
 In all contexts, when converting to the implicit object parameter or
 when converting to the left operand of an assignment operation only
 standard conversion sequences are allowed.
+[*Note 5*: When a conversion to the explicit object parameter occurs,
+it can include user-defined conversion sequences. — *end note*]
 If no conversions are required to match an argument to a parameter type,
 the implicit conversion sequence is the standard conversion sequence
 consisting of the identity conversion [[over.ics.scs]].
 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.
 A conversion of an expression of class type to the same class type is
 given Exact Match rank, and a conversion of an expression of class type
 to a base class of that type is given Conversion rank, in spite of the
 fact that a constructor (i.e., a user-defined conversion function) is
 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 type “reference to cv `T`” binds directly
+[[dcl.init.ref]] to an argument expression:
+- If the argument expression has a type that is a derived class of the
+  parameter type, the implicit conversion sequence is a derived-to-base
+  conversion [[over.best.ics]].
+- Otherwise, if the type of the argument is possibly cv-qualified `T`,
+  or if `T` is an array type of unknown bound with element type `U` and
+  the argument has an array type of known bound whose element type is
+  possibly cv-qualified `U`, the implicit conversion sequence is the
+  identity conversion.
+- Otherwise, if `T` is a function type, the implicit conversion sequence
+  is a function pointer conversion.
+- Otherwise, the implicit conversion sequence is a qualification
+  conversion.
 [*Example 4*:
 ``` cpp
 struct A {};
 struct B : public A {} b;
 int f(A&);
 int f(B&);
 int i = f(b);       // calls f(B&), an exact match, rather than f(A&), a conversion
+void g() noexcept;
+int h(void (&)() noexcept); // #1
+int h(void (&)());          // #2
+int j = h(g);               // calls #1, an exact match, rather than #2, a function pointer conversion
 ```
 — *end example*]
 If the parameter binds directly to the result of applying a conversion
 function to the argument expression, the implicit conversion sequence is
 a user-defined conversion sequence [[over.ics.user]] whose second
+standard conversion sequence is determined by the above rules.
 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
 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 of object type.
 [*Note 9*: 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
 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* and the
+parameter is not a reference, 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 10*:
 Aggregate initialization does not require that the members are declared
 in designation order. If, after overload resolution, the order does not
 f( {'a','b'} );                 // OK, f(initializer_list<int>) integral promotion
 f( {1.0} );                     // error: narrowing
 struct A {
   A(std::initializer_list<double>);                     // #1
+  A(std::initializer_list<std::complex<double>>); // #2
   A(std::initializer_list<std::string>);                // #3
 };
 A a{ 1.0,2.0 };                 // OK, uses #1
 void g(A);
     ```
     — *end example*]
     or, if not that,
   - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
+    binds an lvalue reference to an lvalue of function type and `S2`
+ binds an rvalue reference to an lvalue of function type
     \[*Example 4*:
     ``` cpp
     int f(void(&)());               // #1
     int f(void(&&)());              // #2
     void g();
     ```
     — *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 a standard conversion sequence that is a reference binding is
+    considered to yield the cv-unqualified referenced type), where `T1`
+    and `T2` are not the same type, and `const T2` is
+    reference-compatible with `T1` [[dcl.init.ref]]
     \[*Example 5*:
     ``` cpp
     int f(const volatile int *);
     int f(const int *);
     int i;
     int j = f(&i);                  // calls f(const int*)
+    int g(const int*);
+    int g(const volatile int* const&);
+    int* p;
+    int k = g(p);                   // calls g(const int*)
     ```
     — *end example*]
     or, if not that,
   - `S1`
+    and `S2` bind “reference to `T1`” and “reference to `T2`”,
+ respectively [[dcl.init.ref]], where `T1` and `T2` are not the same
+ type, and `T2` is reference-compatible with `T1`
     \[*Example 6*:
     ``` cpp
     int f(const int &);
     int f(int &);
     int g(const int &);
     };
     void g(const X& a, X b) {
       a.f();                        // calls X::f() const
       b.f();                        // calls X::f()
     }
+    int h(int (&)[]);
+    int h(int (&)[1]);
+    void g2() {
+      int a[1];
+      h(a);                         // calls h(int (&)[1])
+    }
+    ```
+    — *end example*]
+    or, if not that,
+  - `S1` and `S2` bind the same reference type “reference to `T`” and
+    have source types `V1` and `V2`, respectively, where the standard
+    conversion sequence from `V1*` to `T*` is better than the standard
+    conversion sequence from `V2*` to `T*`.
+    \[*Example 7*:
+    ``` cpp
+    struct Z {};
+    struct A {
+      operator Z&();
+      operator const Z&();          // #1
+    };
+    struct B {
+      operator Z();
+      operator const Z&&();         // #2
+    };
+    const Z& r1 = A();              // OK, uses #1
+    const Z&& r2 = B();             // OK, uses #2
     ```
     — *end example*]
 - User-defined conversion sequence `U1` is a better conversion sequence
   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 8*:
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
     to the rank of `FP2`, and
   - `T3` is not a floating-point type, or `T3` is a floating-point type
     whose rank is not equal to the rank of `FP1`, or the floating-point
     conversion subrank [[conv.rank]] of `FP2` is greater than the
     subrank of `T3`.
+    \[*Example 9*:
     ``` cpp
     int f(std::float32_t);
     int f(std::float64_t);
     int f(long long);
     float x;
   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 10*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;

Diff to HTML by rtfpessoa