[over.match.best] - C++20 → C++23

Files changed (1) hide show

tmp/tmpuuf9d83x/{from.md → to.md} +91 -58

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

@@ -1,33 +1,29 @@
 ### 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
 conversion sequence than another.
-Given these definitions, a viable function `F1` is defined to be a
-*better* function than another viable function `F2` if for all arguments
-*i*, ICS*i*(`F1`) is not a worse conversion sequence than ICS*i*(`F2`),
-and then
-- for some argument *j*, ICS*j*(`F1`) is a better conversion sequence
- than ICS*j*(`F2`), 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 `F1` 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 `F2` to the destination type
   \[*Example 1*:
   ``` cpp
   struct A {
     A();
     operator int();
@@ -70,11 +66,11 @@ and then
   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);
   };
@@ -114,10 +110,16 @@ and then
   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
@@ -150,11 +152,11 @@ 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.[^9]
 [*Example 7*:
 ``` cpp
 void Fcn(const int*,  short);
@@ -169,21 +171,20 @@ void f() {
   Fcn(&i, 1L);      // calls Fcn(int*, int), because &i → int* is better than &i → const int*
                     // and 1L → short and 1L → int are indistinguishable
   Fcn(&i, 'c');     // calls Fcn(int*, int), because &i → int* is better than &i → const int*
-                    // and c → int is better than c → short
 }
 ```
 — *end example*]
 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 8*:
 ``` cpp
 namespace A {
@@ -204,16 +205,18 @@ void use() {
 — *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.
@@ -233,11 +236,11 @@ forms:
 - 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
 and the constructor or user-defined conversion function is a candidate
 by
 -  [[over.match.ctor]], when the argument is the temporary in the second
@@ -294,22 +297,29 @@ 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 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
@@ -322,11 +332,11 @@ 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*:
@@ -360,19 +370,19 @@ defined in the following subclauses.
 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*]
@@ -400,14 +410,14 @@ Promotion rank; otherwise, the sequence has Exact Match rank.
 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,
@@ -435,11 +445,11 @@ function called (see  [[expr.call]]).
 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 {};
@@ -451,12 +461,12 @@ 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
@@ -470,11 +480,11 @@ 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*]
@@ -502,11 +512,11 @@ 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]].
@@ -535,14 +545,15 @@ void h() {
 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
@@ -552,13 +563,13 @@ 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
-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
@@ -569,11 +580,11 @@ A a{ 1.0,2.0 };                 // OK, uses #1
 void g(A);
 g({ "foo", "bar" });            // OK, uses #3
 typedef int IA[3];
 void h(const IA&);
-h({ 1, 2, 3 });                 // OK: identity conversion
 ```
 — *end example*]
 Otherwise, if the parameter type is “array of `N` `X`” or “array of
@@ -591,11 +602,11 @@ the argument initializer list:
 - If `C` is not an initializer-list constructor 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 has Exact Match
   rank if `U` is `X`, or Conversion rank if `U` is derived from `X`.
 - Otherwise, the implicit conversion sequence is a user-defined
-  conversion sequence with the second standard conversion sequence an
   identity conversion.
 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
@@ -607,61 +618,61 @@ list elements to the constructor parameter types except as noted in
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
 void f(A);
-f( {'a', 'b'} );        // OK: f(A(std::initializer_list<int>)) user-defined conversion
 struct B {
   B(int, double);
 };
 void g(B);
-g( {'a', 'b'} );        // OK: g(B(int, double)) user-defined conversion
 g( {1.0, 1.0} );        // error: narrowing
 void f(B);
 f( {'a', 'b'} );        // error: ambiguous f(A) or f(B)
 struct C {
   C(std::string);
 };
 void h(C);
-h({"foo"});             // OK: h(C(std::string("foo")))
 struct D {
   D(A, C);
 };
 void i(D);
-i({ {1,2}, {"bar"} });  // OK: i(D(A(std::initializer_list<int>{1,2\), C(std::string("bar"))))}
 ```
 — *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;
 };
 void f(A);
-f( {'a', 'b'} );        // OK: f(A(int,double)) user-defined conversion
 f( {1.0} );             // error: narrowing
 ```
 — *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
@@ -669,11 +680,11 @@ struct A {
   int m1;
   double m2;
 };
 void f(const A&);
-f( {'a', 'b'} );        // OK: f(A(int,double)) user-defined conversion
 f( {1.0} );             // error: narrowing
 void g(const double &);
 g({1});                 // same conversion as int to double
 ```
@@ -686,21 +697,21 @@ Otherwise, if the parameter type is not a class:
   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
   ```
   — *end example*]
 In all cases other than those enumerated above, no conversion is
@@ -889,19 +900,41 @@ 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
   `void*`, and conversion of `A*` to `void*` is better than conversion
   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;

 ### Best viable function <a id="over.match.best">[[over.match.best]]</a>
+#### General <a id="over.match.best.general">[[over.match.best.general]]</a>
+Define ICSⁱ(`F`) as the implicit conversion sequence that converts the
+iᵗʰ argument in the list to the type of the iᵗʰ 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
 conversion sequence than another.
+Given these definitions, a viable function `F₁` is defined to be a
+*better* function than another viable function `F₂` if for all arguments
+i, ICSⁱ(`F₁`) is not a worse conversion sequence than ICSⁱ(`F₂`), and
+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();
   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);
   };
   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
   — *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.[^7]
 [*Example 7*:
 ``` cpp
 void Fcn(const int*,  short);
   Fcn(&i, 1L);      // calls Fcn(int*, int), because &i → int* is better than &i → const int*
                     // and 1L → short and 1L → int are indistinguishable
   Fcn(&i, 'c');     // calls Fcn(int*, int), because &i → int* is better than &i → const int*
+                    // and 'c' → int is better than 'c' → short
 }
 ```
 — *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 {
 — *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>
 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.
 - an ellipsis conversion sequence [[over.ics.ellipsis]].
 However, if the target is
 - the first parameter of a constructor or
+- the object parameter of a user-defined conversion function
 and the constructor or user-defined conversion function is a candidate
 by
 -  [[over.match.ctor]], when the argument is the temporary in the second
 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]].
 If no sequence of conversions can be found to convert an argument to a
 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 6*:
 This rule prevents a function from becoming non-viable because of an
 ambiguous conversion sequence for one of its parameters.
 [*Example 3*:
 summarizes the conversions defined in [[conv]] and partitions them into
 four disjoint categories: Lvalue Transformation, Qualification
 Adjustment, Promotion, and Conversion.
+[*Note 7*: 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 8*: 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*]
 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 of the first parameter of that 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
+type of the object parameter of that 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,
 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]] 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
 [[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
 lvalue reference (see  [[dcl.init.ref]]). — *end note*]
 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
 match for the selected overload, the initialization of the parameter
 will be ill-formed [[dcl.init.list]].
 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[^8]
+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
 [*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
+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
 void g(A);
 g({ "foo", "bar" });            // OK, uses #3
 typedef int IA[3];
 void h(const IA&);
+h({ 1, 2, 3 });                 // OK, identity conversion
 ```
 — *end example*]
 Otherwise, if the parameter type is “array of `N` `X`” or “array of
 - If `C` is not an initializer-list constructor 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 has Exact Match
   rank if `U` is `X`, or Conversion rank if `U` is derived from `X`.
 - Otherwise, the implicit conversion sequence is a user-defined
+  conversion sequence whose second standard conversion sequence is an
   identity conversion.
 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
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
 void f(A);
+f( {'a', 'b'} );        // OK, f(A(std::initializer_list<int>)) user-defined conversion
 struct B {
   B(int, double);
 };
 void g(B);
+g( {'a', 'b'} );        // OK, g(B(int, double)) user-defined conversion
 g( {1.0, 1.0} );        // error: narrowing
 void f(B);
 f( {'a', 'b'} );        // error: ambiguous f(A) or f(B)
 struct C {
   C(std::string);
 };
 void h(C);
+h({"foo"});             // OK, h(C(std::string("foo")))
 struct D {
   D(A, C);
 };
 void i(D);
+i({ {1,2}, {"bar"} });  // OK, i(D(A(std::initializer_list<int>{1,2\), C(std::string("bar"))))}
 ```
 — *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 whose second standard
+conversion sequence is an identity conversion.
 [*Example 9*:
 ``` cpp
 struct A {
   int m1;
   double m2;
 };
 void f(A);
+f( {'a', 'b'} );        // OK, f(A(int,double)) user-defined conversion
 f( {1.0} );             // error: narrowing
 ```
 — *end example*]
 Otherwise, if the parameter is a reference, see  [[over.ics.ref]].
+[*Note 11*: The rules in this subclause will apply for initializing the
 underlying temporary for the reference. — *end note*]
 [*Example 10*:
 ``` cpp
   int m1;
   double m2;
 };
 void f(const A&);
+f( {'a', 'b'} );        // OK, f(A(int,double)) user-defined conversion
 f( {1.0} );             // error: narrowing
 void g(const double &);
 g({1});                 // same conversion as int to double
 ```
   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
   ```
   — *end example*]
 In all cases other than those enumerated above, no conversion is
 - 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.
+- A conversion in either direction between floating-point type `FP1` and
+  floating-point type `FP2` is better than a conversion in the same
+  direction between `FP1` and arithmetic type `T3` if
+  - the floating-point conversion rank [[conv.rank]] of `FP1` is equal
+    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;
+    std::float16_t y;
+    int i = f(x);           // calls f(std::float32_t) on implementations where
+                            // float and std::float32_t have equal conversion ranks
+    int j = f(y);           // error: ambiguous, no equal conversion rank
+    ```
+    — *end example*]
 - If class `B` is derived directly or indirectly from class `A`,
   conversion of `B*` to `A*` is better than conversion of `B*` to
   `void*`, and conversion of `A*` to `void*` is better than conversion
   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;

Diff to HTML by rtfpessoa