[over.match] - C++11 → C++14

Files changed (1) hide show

tmp/tmpg5rfd34z/{from.md → to.md} +170 -88

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

@@ -147,10 +147,14 @@ 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.
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
 In a function call ([[expr.call]])
 ``` bnf
@@ -233,11 +237,11 @@ operators of `T` are obtained by ordinary lookup of the name
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
-'operator' conversion-type-id '( )' attribute-specifier-seqₒₚₜ cv-qualifier ';'
 ```
 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 (`P1`,...,`Pn)` returning `R`”, or the type
@@ -307,13 +311,13 @@ struct String {
 };
 String operator + (const String&, const String&);
 void f(void) {
  const char* p= "one" + "two";  // ill-formed because neither
-                                // operand has user-defined type
  int I = 1 + 1;                 // Always evaluates to 2 even if
-                                // user-defined types exist which
                                 // would perform the operation.
 }
 ```
 If either operand has a type that is a class or an enumeration, a
@@ -344,13 +348,14 @@ 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, 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
@@ -365,12 +370,12 @@ candidates*, are constructed as follows:
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
   - 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-template
- non-member candidate.
 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
@@ -396,15 +401,30 @@ void m() {
   a + b;            // operator+(a,b) chosen over int(a) + int(b)
 }
 ```
 If a built-in candidate is selected by overload resolution, the operands
-are converted to the types of the corresponding parameters of the
-selected operation function. Then the operator is treated as the
 corresponding built-in operator and interpreted according to Clause
 [[expr]].
 The second operand of operator `->` is ignored in selecting an
 `operator->` function, and is not an argument when the `operator->`
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
@@ -449,29 +469,32 @@ the candidate functions are all the converting constructors (
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
 conversion can be invoked to convert an initializer expression to the
 type of the object being initialized. Overload resolution is used to
-select the user-defined conversion to be invoked. 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 that takes a reference to
   possibly cv-qualified `T` as its first argument, called with a single
-  argument in the context of direct-initialization, 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. This argument will be compared against the first
 parameter of the constructors and against the implicit object parameter
 of the conversion functions.
@@ -514,18 +537,23 @@ applying a conversion function to an initializer expression. Overload
 resolution is used to select the conversion function to be invoked.
 Assuming that “*cv1* `T`” is the underlying 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,
- except that for copy-initialization, only the non-explicit conversion
- functions are considered. Those that are not hidden within `S` and
- yield type “lvalue reference to *cv2* `T2`” (when [[dcl.init.ref]]
- requires an lvalue result) or “ `T2`” or “rvalue reference to `T2`”
- (when [[dcl.init.ref]] requires an rvalue result), where “*cv1* `T`”
- is reference-compatible ([[dcl.init.ref]]) with “*cv2* `T2`”, are
-  candidate functions.
 The argument list has one argument, which is the initializer expression.
 This argument will be compared against the implicit object parameter of
 the conversion functions.
@@ -625,12 +653,29 @@ and then
   float x = a;                    // ambiguous: both possibilities require conversions,
                                   // and neither is better than the other
   ```
   or, if not that,
-- `F1` is a non-template function 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]].
@@ -707,20 +752,41 @@ 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, when considering the argument of a constructor or user-defined
-conversion function that is a candidate by  [[over.match.ctor]] when
-invoked for the copying/moving of the temporary in the second step of a
-class copy-initialization, by  [[over.match.list]] when passing the
-initializer list as a single argument or when the initializer list has
-exactly one element and a conversion to some class `X` or reference to
-(possibly cv-qualified) `X` is considered for the first parameter of a
-constructor of `X`, or by  [[over.match.copy]], [[over.match.conv]], or
-[[over.match.ref]] in all cases, only standard conversion sequences and
-ellipsis conversion sequences are considered.
 For the case where the parameter type is a reference, see
 [[over.ics.ref]].
 When the parameter type is not a reference, the implicit conversion
@@ -838,12 +904,12 @@ 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 copy/move constructor (i.e., a user-defined conversion
-function) is called for those cases.
 ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
 An ellipsis conversion sequence occurs when an argument in a function
 call is matched with the ellipsis parameter specification of the
@@ -901,29 +967,27 @@ 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]]).
-The binding of a reference to an expression that is
-*reference-compatible with added qualification* influences the rank of a
-standard conversion; see  [[over.ics.rank]] and  [[dcl.init.ref]].
 ##### 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 `std::initializer_list<X>` or “array of
-`X`”[^12] 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`. This
-conversion can be a user-defined conversion even in the context of a
-call to an initializer-list constructor.
 ``` cpp
 void f(std::initializer_list<int>);
 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 {
@@ -939,19 +1003,27 @@ g({ "foo", "bar" });        // OK, uses #3
 typedef int IA[3];
 void h(const IA&);
 h({ 1, 2, 3 });             // OK: identity conversion
 ```
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor of
 `X` to perform the initialization of an object of type `X` from the
 argument initializer list, the implicit conversion sequence is a
-user-defined conversion sequence. 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]].
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
@@ -961,11 +1033,11 @@ f( {'a', 'b'} );            // OK: f(A(std::initializer_list<int>)) user-defined
 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 {
@@ -973,20 +1045,21 @@ struct C {
 };
 void h(C);
 h({"foo"});                 // OK: h(C(std::string("foo")))
 struct D {
- C(A, C);
 };
 void i(D);
 i({ {1,2}, {"bar"} });      // OK: i(D(A(std::initializer_list<int>{1,2\),C(std::string("bar"))))}
 ```
 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.
 ``` cpp
 struct A {
   int m1;
   double m2;
@@ -1066,23 +1139,10 @@ 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` 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`.
-    ``` cpp
-    int f(const int *);
-    int f(int *);
-    int i;
-    int j = f(&i);                  // calls f(int*)
-    ```
-    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.
     ``` cpp
@@ -1113,15 +1173,30 @@ conversion sequences unless one of the following rules applies:
     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.
     ``` cpp
- template<class T> int f(T&);
- template<class T> int f(T&&);
     void g();
-    int i1 = f(g);                  // calls f(T&)
     ```
   - `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
@@ -1145,33 +1220,40 @@ conversion sequences unless one of the following rules applies:
       b.f();                        // calls X::f()
     }
     ```
 - 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 aggregate
- initialization and the second standard conversion sequence of `U1` is
- better than the second standard conversion sequence of `U2`.
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
   int f(float);
   int i = f(a);                   // calls f(int), because short → int is
                                   // better than short → float.
   ```
 - 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.
 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.
 - 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
@@ -1185,21 +1267,21 @@ indistinguishable unless one of the following rules applies:
     C* pc;
     int f(A*);
     int f(B*);
     int i = f(pc);                  // calls f(B*)
     ```
-  - binding of an expression of type `C` to a reference of type `B&` is
-    better than binding an expression of type `C` to a reference of type
-    `A&`,
   - conversion of `A::*` to `B::*` is better than conversion of `A::*`
     to `C::*`,
   - conversion of `C` to `B` is better than conversion of `C` to `A`,
   - conversion of `B*` to `A*` is better than conversion of `C*` to
     `A*`,
-  - binding of an expression of type `B` to a reference of type `A&` is
-    better than binding an expression of type `C` to a reference of type
-    `A&`,
   - conversion of `B::*` to `C::*` is better than conversion of `A::*`
     to `C::*`, and
   - conversion of `B` to `A` is better than conversion of `C` to `A`.
   Compared conversion sequences will have different source types only in

 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
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
+'operator' conversion-type-id '( )' cv-qualifier ref-qualifierₒₚₜ exception-specificationₒₚₜ 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 (`P1`,...,`Pn)` returning `R`”, or the type
 };
 String operator + (const String&, const String&);
 void f(void) {
  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.
 }
 ```
 If either operand has a type that is a class or an enumeration, 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
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
   - 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
   a + b;            // operator+(a,b) chosen over int(a) + int(b)
 }
 ```
 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]].
+``` cpp
+struct X {
+  operator double();
+};
+struct Y {
+  operator int*();
+};
+int *a = Y() + 100.0;      // error: pointer arithmetic requires integral operand
+int *b = Y() + X();        // error: pointer arithmetic requires integral operand
+```
 The second operand of operator `->` is ignored in selecting an
 `operator->` function, and is not an argument when the `operator->`
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
 conversion can be invoked to convert an initializer expression to the
 type of the object being initialized. Overload resolution is used to
+select the user-defined conversion to be invoked. The conversion
+performed for indirect binding to a reference to a possibly cv-qualified
+class type is determined in terms of a corresponding non-reference
+copy-initialization. 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 that takes a reference to
   possibly cv-qualified `T` as its first argument, 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. This argument will be compared against the first
 parameter of the constructors and against the implicit object parameter
 of the conversion functions.
 resolution is used to select the conversion function to be invoked.
 Assuming that “*cv1* `T`” is the underlying 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 “ `T2`” or
+ “rvalue reference to `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.
 This argument will be compared against the implicit object parameter of
 the conversion functions.
   float x = a;                    // ambiguous: both possibilities require conversions,
                                   // and neither is better than the other
   ```
   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
+  ``` cpp
+  template <class T> struct A {
+    operator T&();        // #1
+    operator T&&();       // #2
+  };
+  typedef int Fn();
+  A<Fn> a;
+  Fn& lf = a;             // calls #1
+  Fn&& rf = a;            // calls #2
+  ```
+  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]].
 - 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
+and the constructor or user-defined conversion function is a candidate
+by
+-  [[over.match.ctor]], when the argument is the temporary in the second
+  step of a class copy-initialization,
+-  [[over.match.copy]], [[over.match.conv]], or [[over.match.ref]] (in
+  all cases), or
+- the second phase of [[over.match.list]] when the initializer list has
+  exactly one element, and the target is the first parameter of a
+  constructor of class `X`, and the conversion is to `X` or reference to
+  (possibly cv-qualified) `X`,
+user-defined conversion sequences are not considered. These rules
+prevent more than one user-defined conversion from being applied during
+overload resolution, thereby avoiding infinite recursion.
+``` 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
+```
 For the case where the parameter type is a reference, see
 [[over.ics.ref]].
 When the parameter type is not a reference, the implicit conversion
 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
+called for those cases.
 ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
 An ellipsis conversion sequence occurs when an argument in a function
 call is matched with the ellipsis parameter specification of the
 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]]).
 ##### 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 `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.
 ``` 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 {
 typedef int IA[3];
 void h(const IA&);
 h({ 1, 2, 3 });             // OK: identity conversion
 ```
+Otherwise, if the parameter type is “array of `N` `X`”[^12], if the
+initializer list has exactly `N` elements or if it has fewer than `N`
+elements and `X` is default-constructible, and if 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`.
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor of
 `X` to perform the initialization of an object of type `X` from the
 argument initializer list, 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 list elements to the constructor parameter
+types except as noted in  [[over.best.ics]].
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
 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 {
 };
 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"))))}
 ```
 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.
 ``` cpp
 struct A {
   int m1;
   double m2;
     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.
     ``` cpp
     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.
     ``` cpp
+    int f(void(&)());               // #1
+    int f(void(&&)());              // #2
     void g();
+    int i1 = f(g);                  // calls #1
     ```
+    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`.
+    ``` cpp
+    int f(const volatile int *);
+    int f(const int *);
+    int i;
+    int j = f(&i);                  // calls f(const int*)
+    ```
+    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
       b.f();                        // calls X::f()
     }
     ```
 - 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`.
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
   int f(float);
   int i = f(a);                   // calls f(int), because short → int is
                                   // better than short → float.
   ```
 - 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`.
 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
   `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
     C* pc;
     int f(A*);
     int f(B*);
     int i = f(pc);                  // calls f(B*)
     ```
+  - binding of an expression of type `C` to a reference to type `B` is
+    better than binding an expression of type `C` to a reference to type
+    `A`,
   - conversion of `A::*` to `B::*` is better than conversion of `A::*`
     to `C::*`,
   - conversion of `C` to `B` is better than conversion of `C` to `A`,
   - conversion of `B*` to `A*` is better than conversion of `C*` to
     `A*`,
+  - binding of an expression of type `B` to a reference to type `A` is
+    better than binding an expression of type `C` to a reference to type
+    `A`,
   - conversion of `B::*` to `C::*` is better than conversion of `A::*`
     to `C::*`, and
   - conversion of `B` to `A` is better than conversion of `C` to `A`.
   Compared conversion sequences will have different source types only in

Diff to HTML by rtfpessoa