[over.match.funcs] - C++14 → C++17

Files changed (1) hide show

tmp/tmpvqjasb6o/{from.md → to.md} +234 -122

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

@@ -25,55 +25,56 @@ object parameter, if present, is always the first parameter and the
 implied object argument, if present, is always the first argument.
 For non-static member functions, the type of the implicit object
 parameter is
-- “lvalue reference to *cv* `X`” for functions declared without a
   *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. for a `const`
-member function of class `X`, the extra parameter is assumed to have
-type “reference to `const X`”. For conversion functions, the function is
-considered to be a member of the class of the implied object argument
-for the purpose of defining the type of the implicit object parameter.
-For non-conversion functions introduced by a *using-declaration* into a
-derived class, the function is considered to be a member of the derived
-class for the purpose of defining the type of the implicit object
-parameter. For static member functions, the implicit object parameter is
-considered to match any object (since if the function is selected, the
-object is discarded). No actual type is established for the implicit
-object parameter of a static member function, and no attempt will be
-made to determine a conversion sequence for that parameter (
-[[over.match.best]]).
 During overload resolution, the implied object argument is
 indistinguishable from other arguments. The implicit object parameter,
-however, retains its identity since conversions on the corresponding
-argument shall obey these additional rules:
-- no temporary object can be introduced to hold the argument for the
-  implicit object parameter; and
-- no user-defined conversions can be applied to achieve a type match
-  with it.
-For non-static member functions declared without a *ref-qualifier*, an
-additional rule applies:
-- even if the implicit object parameter is not `const`-qualified, an
   rvalue can be bound to the parameter as long as in all other respects
   the argument can be converted to the type of the implicit object
-  parameter. The fact that such an argument is an rvalue does not affect
-  the ranking of implicit conversion sequences ([[over.ics.rank]]).
 Because other than in list-initialization only one user-defined
 conversion is allowed in an implicit conversion sequence, special rules
 apply when selecting the best user-defined conversion (
 [[over.match.best]], [[over.best.ics]]).
 ``` cpp
 class T {
 public:
   T();
 };
@@ -83,10 +84,12 @@ public:
   C(int);
 };
 T a = 1;            // ill-formed: T(C(1)) not tried
 ```
 In each case where a candidate is a function template, candidate
 function template specializations are generated using template argument
 deduction ([[temp.over]], [[temp.deduct]]). Those candidates are then
 handled as candidate functions in the usual way.[^2] A given name can
 refer to one or more function templates and also to a set of overloaded
@@ -114,12 +117,13 @@ class type, overload resolution is applied as specified in
 If the *postfix-expression* denotes the address of a set of overloaded
 functions and/or function templates, overload resolution is applied
 using that set as described above. If the function selected by overload
 resolution is a non-static member function, the program is ill-formed.
-The resolution of the address of an overload set in other contexts is
-described in [[over.over]].
 ##### 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 a name that denotes
@@ -142,12 +146,12 @@ In qualified function calls, the name to be resolved is an
 construct `A->B` is generally equivalent to `(*A).B`, the rest of
 Clause  [[over]] assumes, without loss of generality, that all member
 function calls have been normalized to the form that uses an object and
 the `.` operator. Furthermore, Clause  [[over]] assumes that the
 *postfix-expression* that is the left operand of the `.` operator has
-type “*cv* `T`” where `T` denotes a class[^3]. Under this assumption,
-the *id-expression* in the call is looked up as a member function of `T`
 following the rules for looking up names in classes (
 [[class.member.lookup]]). The function declarations found by that lookup
 constitute the set of candidate functions. The argument list is the
 *expression-list* in the call augmented by the addition of the left
 operand of the `.` operator in the normalized member function call as
@@ -173,32 +177,33 @@ and overload resolution selects one of the non-static member functions
 of `T`, the call is ill-formed.
 ##### Call to object of class type <a id="over.call.object">[[over.call.object]]</a>
 If the *primary-expression* `E` in the function call syntax evaluates to
-a class object of type “*cv* `T`”, then the set of candidate functions
 includes at least the function call operators of `T`. The function call
 operators of `T` are obtained by ordinary lookup of the name
 `operator()` in the context of `(E).operator()`.
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
-'operator' conversion-type-id '( )' cv-qualifier ref-qualifierₒₚₜ 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
-“reference to pointer to function of (`P1`,...,`Pn)` returning `R`”, or
-the type “reference to function of (`P1`,...,`Pn)` returning `R`”, a
 *surrogate call function* with the unique name *call-function* and
 having the form
 ``` bnf
-'R' call-function '(' conversion-type-id 'F, P1 a1, ... ,Pn an)' '{ return F (a1,... ,an); }'
 ```
 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`
@@ -212,82 +217,92 @@ then be invoked with the arguments of the call. If the conversion
 function cannot be called (e.g., because of an ambiguity), the program
 is ill-formed.
 The argument list submitted to overload resolution consists of the
 argument expressions present in the function call syntax preceded by the
-implied object argument `(E)`. When comparing the call against the
-function call operators, the implied object argument is compared against
-the implicit object parameter of the function call operator. When
-comparing the call against a surrogate call function, the implied object
-argument is compared against the first parameter of the surrogate call
-function. The conversion function from which the surrogate call function
-was derived will be used in the conversion sequence for that parameter
-since it converts the implied object argument to the appropriate
-function pointer or reference required by that first parameter.
 ``` cpp
 int f1(int);
 int f2(float);
 typedef int (*fp1)(int);
 typedef int (*fp2)(float);
 struct A {
   operator fp1() { return f1; }
   operator fp2() { return f2; }
 } a;
-int i = a(1); // calls f1 via pointer returned from
-                    // conversion function
 ```
 #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
 If no operand of an operator in an expression has a type that is a class
 or an enumeration, the operator is assumed to be a built-in operator and
-interpreted according to Clause  [[expr]]. Because `.`, `.*`, and `::`
-cannot be overloaded, these operators are always built-in operators
-interpreted according to Clause  [[expr]]. `?:` cannot be overloaded,
-but the rules in this subclause are used to determine the conversions to
-be applied to the second and third operands when they have class or
-enumeration type ([[expr.cond]]).
 ``` cpp
 struct String {
   String (const String&);
   String (const char*);
   operator const char* ();
 };
 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
 user-defined operator function might be declared that implements this
 operator or a user-defined conversion can be necessary to convert the
 operand to a type that is appropriate for a built-in operator. In this
 case, overload resolution is used to determine which operator function
 or built-in operator is to be invoked to implement the operator.
 Therefore, the operator notation is first transformed to the equivalent
 function-call notation as summarized in Table  [[tab:over.rel.op.func]]
 (where `@` denotes one of the operators covered in the specified
-subclause).
 **Table: Relationship between operator and function call notation** <a id="tab:over.rel.op.func">[tab:over.rel.op.func]</a>
 | Subclause    | Expression | As member function  | As non-member function |
-| ------------ | ---------- | ------------------ | ---------------------- |
-| (a) |
-| (a, b) |
-| [[over.ass]] | a=b | (a).operator= (b) |                        |
-| [[over.sub]] | a[b] | (a).operator[](b) |                        |
-| [[over.ref]] | a-> | (a).operator-> ( ) |                        |
-| (a, 0) |
 For a unary operator `@` with an operand of a type whose cv-unqualified
 version is `T1`, and for a binary operator `@` with a left operand of a
 type whose cv-unqualified version is `T1` and a right operand of a type
@@ -303,14 +318,14 @@ candidates*, are constructed as follows:
   lookup of `operator@` in the context of the expression according to
   the usual rules for name lookup in unqualified function calls (
   [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   functions in the lookup set that have a first parameter of type `T1`
-  or “reference to (possibly cv-qualified) `T1`”, when `T1` is an
- enumeration type, or (if there is a right operand) a second parameter
- of type `T2` or “reference to (possibly cv-qualified) `T2`”, when `T2`
- is an enumeration type, are candidate functions.
 - For the operator `,`, the unary operator `&`, or the operator `->`,
   the built-in candidates set is empty. For all other operators, the
   built-in candidates include all of the candidate operator functions
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
@@ -334,10 +349,12 @@ the member candidates, the non-member candidates, and the built-in
 candidates. The argument list contains all of the operands of the
 operator. The best function from the set of candidate functions is
 selected according to  [[over.match.viable]] and
 [[over.match.best]].[^6]
 ``` cpp
 struct A {
   operator int();
 };
 A operator+(const A&, const A&);
@@ -345,18 +362,22 @@ void m() {
   A a, b;
   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();
 };
@@ -366,20 +387,24 @@ struct Y {
 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]
 If the operator is the operator `,`, the unary operator `&`, or the
 operator `->`, and there are no viable functions, then the operator is
 assumed to be the built-in operator and interpreted according to Clause
 [[expr]].
 The lookup rules for operators in expressions are different than the
 lookup rules for operator function names in a function call, as shown in
 the following example:
 ``` cpp
@@ -397,64 +422,72 @@ void B::f() {
   operator+ (a,a);              // error: global operator hidden by member
   a + a;                        // OK: calls global operator+
 }
 ```
 #### Initialization by constructor <a id="over.match.ctor">[[over.match.ctor]]</a>
-When objects of class type are direct-initialized ([[dcl.init]]), or
 copy-initialized from an expression of the same or a derived class
-type ([[dcl.init]]), overload resolution selects the constructor. For
-direct-initialization, the candidate functions are all the constructors
-of the class of the object being initialized. For copy-initialization,
-the candidate functions are all the converting constructors (
 [[class.conv.ctor]]) of that class. The argument list is the
 *expression-list* or *assignment-expression* of the *initializer*.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
 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.
 #### Initialization by conversion function <a id="over.match.conv">[[over.match.conv]]</a>
 Under the conditions specified in  [[dcl.init]], as part of an
-initialization of an object of nonclass type, a conversion function can
 be invoked to convert an initializer expression of class type to the
 type of the object being initialized. Overload resolution is used to
 select the conversion function to be invoked. Assuming that “*cv1* `T`”
-is the type of the object 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 `T` or a type that can be converted to type `T` via a
@@ -469,46 +502,50 @@ functions are selected as follows:
   return lvalues or xvalues, depending on the type of reference, of type
   “*cv2* `X`” and are therefore considered to yield `X` for this process
   of selecting candidate functions.
 The argument list has one argument, which is the initializer expression.
-This argument will be compared against the implicit object parameter of
-the conversion functions.
 #### Initialization by conversion function for direct reference binding <a id="over.match.ref">[[over.match.ref]]</a>
 Under the conditions specified in  [[dcl.init.ref]], a reference can be
 bound directly to a glvalue or class prvalue that is the result of
 applying a conversion function to an initializer expression. Overload
 resolution is used to select the conversion function to be invoked.
-Assuming that “*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.
 #### Initialization by list-initialization <a id="over.match.list">[[over.match.list]]</a>
-When objects of non-aggregate class type `T` are list-initialized (
-[[dcl.init.list]]), overload resolution selects the constructor in two
-phases:
 - Initially, the candidate functions are the initializer-list
   constructors ([[dcl.init.list]]) of the class `T` and the argument
   list consists of the initializer list as a single argument.
 - If no viable initializer-list constructor is found, overload
@@ -517,10 +554,85 @@ phases:
   the elements of the initializer list.
 If the initializer list has no elements and `T` has a default
 constructor, the first phase is omitted. In copy-list-initialization, if
 an `explicit` constructor is chosen, the initialization is ill-formed.
-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.

 implied object argument, if present, is always the first argument.
 For non-static member functions, the type of the implicit object
 parameter is
+- “lvalue reference to cv `X`” for functions declared without a
   *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 “reference to
+`const X`”. — *end example*]
+For conversion functions, the function is considered to be a member of
+the class of the implied object argument for the purpose of defining the
+type of the implicit object parameter. For non-conversion functions
+introduced by a *using-declaration* into a derived class, the function
+is considered to be a member of the derived class for the purpose of
+defining the type of the implicit object parameter. For static member
+functions, the implicit object parameter is considered to match any
+object (since if the function is selected, the object is discarded).
+[*Note 1*: No actual type is established for the implicit object
+parameter of a static member function, and no attempt will be made to
+determine a conversion sequence for that parameter (
+[[over.match.best]]). — *end note*]
 During overload resolution, the implied object argument is
 indistinguishable from other arguments. The implicit object parameter,
+however, retains its identity since no user-defined conversions can be
+applied to achieve a type match with it. For non-static member functions
+declared without a *ref-qualifier*, an additional rule applies:
+- even if the implicit object parameter is not const-qualified, an
   rvalue can be bound to the parameter as long as in all other respects
   the argument can be converted to the type of the implicit object
+  parameter. \[*Note 2*: The fact that such an argument is an rvalue
+ does not affect the ranking of implicit conversion sequences (
+  [[over.ics.rank]]). — *end note*]
 Because other than in list-initialization only one user-defined
 conversion is allowed in an implicit conversion sequence, special rules
 apply when selecting the best user-defined conversion (
 [[over.match.best]], [[over.best.ics]]).
+[*Example 2*:
 ``` cpp
 class T {
 public:
   T();
 };
   C(int);
 };
 T a = 1;            // ill-formed: T(C(1)) not tried
 ```
+— *end example*]
 In each case where a candidate is a function template, candidate
 function template specializations are generated using template argument
 deduction ([[temp.over]], [[temp.deduct]]). Those candidates are then
 handled as candidate functions in the usual way.[^2] A given name can
 refer to one or more function templates and also to a set of overloaded
 If the *postfix-expression* denotes the address of a set of overloaded
 functions and/or function templates, overload resolution is applied
 using that set as described above. If the function selected by overload
 resolution is a non-static member function, the program is ill-formed.
+[*Note 1*: The resolution of the address of an overload set in other
+contexts is described in [[over.over]]. — *end note*]
 ##### Call to named function <a id="over.call.func">[[over.call.func]]</a>
 Of interest in  [[over.call.func]] are only those function calls in
 which the *postfix-expression* ultimately contains a name that denotes
 construct `A->B` is generally equivalent to `(*A).B`, the rest of
 Clause  [[over]] assumes, without loss of generality, that all member
 function calls have been normalized to the form that uses an object and
 the `.` operator. Furthermore, Clause  [[over]] assumes that the
 *postfix-expression* that is the left operand of the `.` operator has
+type “cv `T`” where `T` denotes a class[^3]. Under this assumption, the
+*id-expression* in the call is looked up as a member function of `T`
 following the rules for looking up names in classes (
 [[class.member.lookup]]). The function declarations found by that lookup
 constitute the set of candidate functions. The argument list is the
 *expression-list* in the call augmented by the addition of the left
 operand of the `.` operator in the normalized member function call as
 of `T`, the call is ill-formed.
 ##### Call to object of class type <a id="over.call.object">[[over.call.object]]</a>
 If the *primary-expression* `E` in the function call syntax evaluates to
+a class object of type “cv `T`”, then the set of candidate functions
 includes at least the function call operators of `T`. The function call
 operators of `T` are obtained by ordinary lookup of the name
 `operator()` in the context of `(E).operator()`.
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
+'operator' conversion-type-id '( )' cv-qualifier ref-qualifierₒₚₜ noexcept-specifierₒₚₜ attribute-specifier-seqₒₚₜ ';'
 ```
 where *cv-qualifier* is the same cv-qualification as, or a greater
+cv-qualification than, cv, and where *conversion-type-id* denotes the
+type “pointer to function of (`P₁`, …, `Pₙ`) returning `R`”, or the type
+“reference to pointer to function of (`P₁`, …, `Pₙ`) returning `R`”, or
+the type “reference to function of (`P₁`, …, `Pₙ`) returning `R`”, a
 *surrogate call function* with the unique name *call-function* and
 having the form
 ``` bnf
+'R' call-function '(' conversion-type-id \ %
+'F, P₁ a₁, …, Pₙ aₙ)' '{ return F (a₁, …, aₙ); }'
 ```
 is also considered as a candidate function. Similarly, surrogate call
 functions are added to the set of candidate functions for each
 non-explicit conversion function declared in a base class of `T`
 function cannot be called (e.g., because of an ambiguity), the program
 is ill-formed.
 The argument list submitted to overload resolution consists of the
 argument expressions present in the function call syntax preceded by the
+implied object argument `(E)`.
+[*Note 2*: When comparing the call against the function call operators,
+the implied object argument is compared against the implicit object
+parameter of the function call operator. When comparing the call against
+a surrogate call function, the implied object argument is compared
+against the first parameter of the surrogate call function. The
+conversion function from which the surrogate call function was derived
+will be used in the conversion sequence for that parameter since it
+converts the implied object argument to the appropriate function pointer
+or reference required by that first parameter. — *end note*]
+[*Example 1*:
 ``` cpp
 int f1(int);
 int f2(float);
 typedef int (*fp1)(int);
 typedef int (*fp2)(float);
 struct A {
   operator fp1() { return f1; }
   operator fp2() { return f2; }
 } a;
+int i = a(1); // calls f1 via pointer returned from conversion function
 ```
+— *end example*]
 #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
 If no operand of an operator in an expression has a type that is a class
 or an enumeration, the operator is assumed to be a built-in operator and
+interpreted according to Clause  [[expr]].
+[*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
+operators are always built-in operators interpreted according to Clause
+[[expr]]. `?:` cannot be overloaded, but the rules in this subclause are
+used to determine the conversions to be applied to the second and third
+operands when they have class or enumeration type (
+[[expr.cond]]). — *end note*]
+[*Example 1*:
 ``` cpp
 struct String {
   String (const String&);
   String (const char*);
   operator const char* ();
 };
 String operator + (const String&, const String&);
+void f() {
+ const char* p= "one" + "two";  // ill-formed because neither operand has class or enumeration type
+ int I = 1 + 1;                 // always evaluates to 2 even if class or enumeration types exist
+ // that would perform the operation.
 }
 ```
+— *end example*]
 If either operand has a type that is a class or an enumeration, a
 user-defined operator function might be declared that implements this
 operator or a user-defined conversion can be necessary to convert the
 operand to a type that is appropriate for a built-in operator. In this
 case, overload resolution is used to determine which operator function
 or built-in operator is to be invoked to implement the operator.
 Therefore, the operator notation is first transformed to the equivalent
 function-call notation as summarized in Table  [[tab:over.rel.op.func]]
 (where `@` denotes one of the operators covered in the specified
+subclause). However, the operands are sequenced in the order prescribed
+for the built-in operator (Clause  [[expr]]).
 **Table: Relationship between operator and function call notation** <a id="tab:over.rel.op.func">[tab:over.rel.op.func]</a>
 | Subclause    | Expression | As member function  | As non-member function |
+| ------------ | ---------- | ------------------- | ---------------------- |
+| (a)}         |
+| (a, b)}      |
+| [[over.ass]] | `a=b`      | `(a).operator= (b)` |                        |
+| [[over.sub]] | `a[b]`     | `(a).operator[](b)` |                        |
+| [[over.ref]] | `a->`      | `(a).operator->( )` |                        |
+| (a, 0)}      |
 For a unary operator `@` with an operand of a type whose cv-unqualified
 version is `T1`, and for a binary operator `@` with a left operand of a
 type whose cv-unqualified version is `T1` and a right operand of a type
   lookup of `operator@` in the context of the expression according to
   the usual rules for name lookup in unqualified function calls (
   [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   functions in the lookup set that have a first parameter of type `T1`
+  or “reference to cv `T1`”, when `T1` is an enumeration type, or (if
+  there is a right operand) a second parameter of type `T2` or
+  “reference to cv `T2`”, when `T2` is an enumeration type, are
+  candidate functions.
 - For the operator `,`, the unary operator `&`, or the operator `->`,
   the built-in candidates set is empty. For all other operators, the
   built-in candidates include all of the candidate operator functions
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
 candidates. The argument list contains all of the operands of the
 operator. The best function from the set of candidate functions is
 selected according to  [[over.match.viable]] and
 [[over.match.best]].[^6]
+[*Example 2*:
 ``` cpp
 struct A {
   operator int();
 };
 A operator+(const A&, const A&);
   A a, b;
   a + b;                        // operator+(a, b) chosen over int(a) + int(b)
 }
 ```
+— *end example*]
 If a built-in candidate is selected by overload resolution, the operands
 of class type are converted to the types of the corresponding parameters
 of the selected operation function, except that the second standard
 conversion sequence of a user-defined conversion sequence (
 [[over.ics.user]]) is not applied. Then the operator is treated as the
 corresponding built-in operator and interpreted according to Clause
 [[expr]].
+[*Example 3*:
 ``` cpp
 struct X {
   operator double();
 };
 int *a = Y() + 100.0;           // error: pointer arithmetic requires integral operand
 int *b = Y() + X();             // error: pointer arithmetic requires integral operand
 ```
+— *end example*]
 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]
 If the operator is the operator `,`, the unary operator `&`, or the
 operator `->`, and there are no viable functions, then the operator is
 assumed to be the built-in operator and interpreted according to Clause
 [[expr]].
+[*Note 2*:
 The lookup rules for operators in expressions are different than the
 lookup rules for operator function names in a function call, as shown in
 the following example:
 ``` cpp
   operator+ (a,a);              // error: global operator hidden by member
   a + a;                        // OK: calls global operator+
 }
 ```
+— *end note*]
 #### Initialization by constructor <a id="over.match.ctor">[[over.match.ctor]]</a>
+When objects of class type are direct-initialized ([[dcl.init]]),
 copy-initialized from an expression of the same or a derived class
+type ([[dcl.init]]), or default-initialized ([[dcl.init]]), overload
+resolution selects the constructor. For direct-initialization or
+default-initialization that is not in the context of
+copy-initialization, the candidate functions are all the constructors of
+the class of the object being initialized. For copy-initialization, the
+candidate functions are all the converting constructors (
 [[class.conv.ctor]]) of that class. The argument list is the
 *expression-list* or *assignment-expression* of the *initializer*.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
 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.
+[*Note 1*: 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. — *end note*]
+Assuming that “*cv1* `T`” is the type of the object being initialized,
+with `T` a class type, the candidate functions are selected as follows:
 - The converting constructors ([[class.conv.ctor]]) of `T` are
   candidate functions.
+- When the type of the initializer expression is a class type “cv `S`”,
+  the non-explicit conversion functions of `S` and its base classes are
+  considered. When initializing a temporary to be bound to the first
+  parameter of a constructor where the parameter is of type “reference
+ to possibly cv-qualified `T`” and the constructor is called with a
+ single argument in the context of direct-initialization of an object
+ of type “*cv2* `T`”, explicit conversion functions are also
+ considered. Those that are not hidden within `S` and yield a type
+ whose cv-unqualified version is the same type as `T` or is a derived
+ class thereof are candidate functions. Conversion functions that
+ return “reference to `X`” return lvalues or xvalues, depending on the
+  type of reference, of type `X` and are therefore considered to yield
+ `X` for this process of selecting candidate functions.
 In both cases, the argument list has one argument, which is the
+initializer expression.
+[*Note 2*: This argument will be compared against the first parameter
+of the constructors and against the implicit object parameter of the
+conversion functions. — *end note*]
 #### Initialization by conversion function <a id="over.match.conv">[[over.match.conv]]</a>
 Under the conditions specified in  [[dcl.init]], as part of an
+initialization of an object of non-class type, a conversion function can
 be invoked to convert an initializer expression of class type to the
 type of the object being initialized. Overload resolution is used to
 select the conversion function to be invoked. Assuming that “*cv1* `T`”
+is the type of the object 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 `T` or a type that can be converted to type `T` via a
   return lvalues or xvalues, depending on the type of reference, of type
   “*cv2* `X`” and are therefore considered to yield `X` for this process
   of selecting candidate functions.
 The argument list has one argument, which is the initializer expression.
+[*Note 1*: This argument will be compared against the implicit object
+parameter of the conversion functions. — *end note*]
 #### Initialization by conversion function for direct reference binding <a id="over.match.ref">[[over.match.ref]]</a>
 Under the conditions specified in  [[dcl.init.ref]], a reference can be
 bound directly to a glvalue or class prvalue that is the result of
 applying a conversion function to an initializer expression. Overload
 resolution is used to select the conversion function to be invoked.
+Assuming that “reference to *cv1* `T`” is the type of the reference
+being initialized, and “cv `S`” is the type of the initializer
+expression, with `S` a class type, the candidate functions are selected
+as follows:
 - The conversion functions of `S` and its base classes are considered.
   Those non-explicit conversion functions that are not hidden within `S`
   and yield type “lvalue reference to *cv2* `T2`” (when initializing an
+  lvalue reference or an rvalue reference to function) or “*cv2* `T2`”
+ or “rvalue reference to *cv2* `T2`” (when initializing an rvalue
+ reference or an lvalue reference to function), where “*cv1* `T`” is
   reference-compatible ([[dcl.init.ref]]) with “*cv2* `T2`”, are
   candidate functions. For direct-initialization, those explicit
   conversion functions that are not hidden within `S` and yield type
   “lvalue reference to *cv2* `T2`” or “*cv2* `T2`” or “rvalue reference
+  to *cv2* `T2`”, respectively, where `T2` is the same type as `T` or
   can be converted to type `T` with a qualification conversion (
   [[conv.qual]]), are also candidate functions.
 The argument list has one argument, which is the initializer expression.
+[*Note 1*: This argument will be compared against the implicit object
+parameter of the conversion functions. — *end note*]
 #### Initialization by list-initialization <a id="over.match.list">[[over.match.list]]</a>
+When objects of non-aggregate class type `T` are list-initialized such
+that [[dcl.init.list]] specifies that overload resolution is performed
+according to the rules in this section, overload resolution selects the
+constructor in two phases:
 - Initially, the candidate functions are the initializer-list
   constructors ([[dcl.init.list]]) of the class `T` and the argument
   list consists of the initializer list as a single argument.
 - If no viable initializer-list constructor is found, overload
   the elements of the initializer list.
 If the initializer list has no elements and `T` has a default
 constructor, the first phase is omitted. In copy-list-initialization, if
 an `explicit` constructor is chosen, the initialization is ill-formed.
+[*Note 1*: This differs from other situations ([[over.match.ctor]],
 [[over.match.copy]]), where only converting constructors are considered
 for copy-initialization. This restriction only applies if this
+initialization is part of the final result of overload
+resolution. — *end note*]
+#### Class template argument deduction <a id="over.match.class.deduct">[[over.match.class.deduct]]</a>
+A set of functions and function templates is formed comprising:
+- For each constructor of the primary class template designated by the
+  *template-name*, if the template is defined, a function template with
+  the following properties:
+  - The template parameters are the template parameters of the class
+    template followed by the template parameters (including default
+    template arguments) of the constructor, if any.
+  - The types of the function parameters are those of the constructor.
+  - The return type is the class template specialization designated by
+    the *template-name* and template arguments corresponding to the
+    template parameters obtained from the class template.
+- If the primary class template `C` is not defined or does not declare
+  any constructors, an additional function template derived as above
+  from a hypothetical constructor `C()`.
+- An additional function template derived as above from a hypothetical
+  constructor `C(C)`, called the *copy deduction candidate*.
+- For each *deduction-guide*, a function or function template with the
+  following properties:
+  - The template parameters, if any, and function parameters are those
+    of the *deduction-guide*.
+  - The return type is the *simple-template-id* of the
+    *deduction-guide*.
+Initialization and overload resolution are performed as described in
+[[dcl.init]] and [[over.match.ctor]], [[over.match.copy]], or
+[[over.match.list]] (as appropriate for the type of initialization
+performed) for an object of a hypothetical class type, where the
+selected functions and function templates are considered to be the
+constructors of that class type for the purpose of forming an overload
+set, and the initializer is provided by the context in which class
+template argument deduction was performed. Each such notional
+constructor is considered to be explicit if the function or function
+template was generated from a constructor or *deduction-guide* that was
+declared `explicit`. All such notional constructors are considered to be
+public members of the hypothetical class type.
+[*Example 1*:
+``` cpp
+template <class T> struct A {
+  explicit A(const T&, ...) noexcept;  // #1
+  A(T&&, ...);                         // #2
+};
+int i;
+A a1 = { i, i };    // error: explicit constructor #1 selected in copy-list-initialization during deduction,
+                    // cannot deduce from non-forwarding rvalue reference in #2
+A a2{i, i};         // OK, #1 deduces to A<int> and also initializes
+A a3{0, i};         // OK, #2 deduces to A<int> and also initializes
+A a4 = {0, i};      // OK, #2 deduces to A<int> and also initializes
+template <class T> A(const T&, const T&) -> A<T&>;  // #3
+template <class T> explicit A(T&&, T&&) -> A<T>;    // #4
+A a5 = {0, 1};      // error: explicit deduction guide #4 selected in copy-list-initialization during deduction
+A a6{0,1};          // OK, #4 deduces to A<int> and #2 initializes
+A a7 = {0, i};      // error: #3 deduces to A<int&>, #1 and #2 declare same constructor
+A a8{0,i};          // error: #3 deduces to A<int&>, #1 and #2 declare same constructor
+template <class T> struct B {
+  template <class U> using TA = T;
+  template <class U> B(U, TA<U>);
+};
+B b{(int*)0, (char*)0};         // OK, deduces B<char*>
+```
+— *end example*]

Diff to HTML by rtfpessoa