[over.best.ics] - C++23 → Trunk

Files changed (1) hide show

tmp/tmpx8b0dppy/{from.md → to.md} +54 -40

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

@@ -11,17 +11,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]],
@@ -78,40 +78,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]].
@@ -218,11 +218,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
@@ -234,34 +234,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
@@ -271,11 +284,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
@@ -298,16 +311,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
@@ -363,11 +377,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);

 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);

Diff to HTML by rtfpessoa