[over] - C++23 → Trunk

Files changed (1) hide show

tmp/tmpzy6drflg/{from.md → to.md} +400 -242

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

@@ -4,17 +4,21 @@
 [*Note 1*: Each of two or more entities with the same name in the same
 scope, which must be functions or function templates, is commonly called
 an “overload”. — *end note*]
-When a function is named in a call, which function declaration is being
-referenced and the validity of the call are determined by comparing the
-types of the arguments at the point of use with the types of the
-parameters in the declarations in the overload set. This function
 selection process is called *overload resolution* and is defined in
 [[over.match]].
 [*Example 1*:
 ``` cpp
 double abs(double);
 int abs(int);
@@ -121,12 +125,12 @@ parameter is
 - “lvalue reference to cv `X`” for functions declared without a
   *ref-qualifier* or with the `&` *ref-qualifier*
 - “rvalue reference to cv `X`” for functions declared with the `&&`
   *ref-qualifier*
-where `X` is the class of which the function is a member and cv is the
-cv-qualification on the member function declaration.
 [*Example 1*: For a `const` member function of class `X`, the extra
 parameter is assumed to have type “lvalue reference to
 `const X`”. — *end example*]
@@ -278,63 +282,80 @@ If the function selected by overload resolution is an implicit object
 member function, the program is ill-formed.
 [*Note 2*: The resolution of the address of an overload set in other
 contexts is described in [[over.over]]. — *end note*]
-##### Call to named function <a id="over.call.func">[[over.call.func]]</a>
 Of interest in  [[over.call.func]] are only those function calls in
-which the *postfix-expression* ultimately contains an *id-expression*
-that denotes one or more functions. Such a *postfix-expression*, perhaps
-nested arbitrarily deep in parentheses, has one of the following forms:
 ``` bnf
 postfix-expression:
     postfix-expression '.' id-expression
     postfix-expression '->' id-expression
- primary-expression
 ```
 These represent two syntactic subcategories of function calls: qualified
 function calls and unqualified function calls.
-In qualified function calls, the function is named by an *id-expression*
-preceded by an `->` or `.` operator. Since the construct `A->B` is
-generally equivalent to `(*A).B`, the rest of [[over]] assumes, without
-loss of generality, that all member function calls have been normalized
-to the form that uses an object and the `.` operator. Furthermore,
-[[over]] assumes that the *postfix-expression* that is the left operand
-of the `.` operator has type “cv `T`” where `T` denotes a class.[^2]
-The function declarations found by name lookup [[class.member.lookup]]
-constitute the set of candidate functions. The argument list is the
-*expression-list* in the call augmented by the addition of the left
-operand of the `.` operator in the normalized member function call as
-the implied object argument [[over.match.funcs]].
-In unqualified function calls, the function is named by a
-*primary-expression*. The function declarations found by name lookup
-[[basic.lookup]] constitute the set of candidate functions. Because of
-the rules for name lookup, the set of candidate functions consists
-either entirely of non-member functions or entirely of member functions
-of some class `T`. In the former case or if the *primary-expression* is
-the address of an overload set, the argument list is the same as the
-*expression-list* in the call. Otherwise, the argument list is the
-*expression-list* in the call augmented by the addition of an implied
-object argument as in a qualified function call. If the current class
-is, or is derived from, `T`, and the keyword `this` [[expr.prim.this]]
-refers to it, then the implied object argument is `(*this)`. Otherwise,
-a contrived object of type `T` becomes the implied object argument;[^3]
-if overload resolution selects a non-static member function, the call is
-ill-formed.
 [*Example 1*:
 ``` cpp
 struct C {
- void a();
   void b() {
     a();                // OK, (*this).a()
   }
   void c(this const C&);    // #1
@@ -367,10 +388,19 @@ void d() {
   void k(this int);
   operator int() const;
   void m(this const C& c) {
     c.k();              // OK
   }
 };
 ```
 — *end example*]
@@ -397,11 +427,11 @@ returning `R`”, or the type “reference to function of (`P₁`, …, `Pₙ`)
 returning `R`”, a *surrogate call function* with the unique name
 *call-function* and having the form
 ``` bnf
 'R' *call-function* '(' conversion-type-id \ %
-'F, P₁ a₁, …, Pₙ aₙ)' '{ return F (a₁, …, aₙ); }'
 ```
 is also considered as a candidate function. Similarly, surrogate call
 functions are added to the set of candidate functions for each
 non-explicit conversion function declared in a base class of `T`
@@ -480,14 +510,14 @@ However, the operands are sequenced in the order prescribed for the
 built-in operator [[expr.compound]].
 **Table: Relationship between operator and function call notation** <a id="over.match.oper">[over.match.oper]</a>
 | Subclause       | Expression | As member function  | As non-member function |
-| ------------ | ---------- | ------------------- | ---------------------- |
 | (a)}            |
 | (a, b)}         |
-| [[over.ass]] | `a=b`      | `(a).operator= (b)` |                        |
 | [[over.sub]]    | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]]    | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}         |
@@ -584,16 +614,12 @@ inline namespace N {
 bool d1 = 0 == D();             // OK, calls reversed #4; #5 does not forbid #4 as a rewrite target
 ```
 — *end example*]
-For the built-in assignment operators, conversions of the left operand
-are restricted as follows:
-- no temporaries are introduced to hold the left operand, and
-- no user-defined conversions are applied to the left operand to achieve
-  a type match with the left-most parameter of a built-in candidate.
 For all other operators, no such restrictions apply.
 The set of candidate functions for overload resolution for some operator
 `@` is the union of the member candidates, the non-member candidates,
@@ -702,17 +728,18 @@ void B::f() {
 When objects of class type are direct-initialized [[dcl.init]],
 copy-initialized from an expression of the same or a derived class type
 [[dcl.init]], or default-initialized [[dcl.init]], overload resolution
 selects the constructor. For direct-initialization or
-default-initialization that is not in the context of
-copy-initialization, the candidate functions are all the constructors of
-the class of the object being initialized. For copy-initialization
-(including default initialization in the context of
-copy-initialization), the candidate functions are all the converting
-constructors [[class.conv.ctor]] of that class. The argument list is the
-*expression-list* or *assignment-expression* of the *initializer*.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
@@ -725,11 +752,11 @@ to a possibly cv-qualified class type is determined in terms of a
 corresponding non-reference copy-initialization. — *end note*]
 Assuming that “*cv1* `T`” is the type of the object being initialized,
 with `T` a class type, the candidate functions are selected as follows:
-- The converting constructors [[class.conv.ctor]] of `T` are candidate
   functions.
 - When the type of the initializer expression is a class type “cv `S`”,
   conversion functions are considered. The permissible types for
   non-explicit conversion functions are `T` and any class derived from
   `T`. When initializing a temporary object [[class.mem]] to be bound to
@@ -776,14 +803,13 @@ initializer expression. Overload resolution is used to select the
 conversion function to be invoked. Assuming that “reference to *cv1*
 `T`” is the type of the reference being initialized, the candidate
 functions are selected as follows:
 - Let R be a set of types including
-  - “lvalue reference to *cv2* `T2`” (when initializing an lvalue
-    reference or an rvalue reference to function) and
-  - “*cv2* `T2`” and “rvalue reference to *cv2* `T2`” (when initializing
-    an rvalue reference or an lvalue reference to function)
   for any `T2`. The permissible types for non-explicit conversion
   functions are the members of R where “*cv1* `T`” is
   reference-compatible [[dcl.init.ref]] with “*cv2* `T2`”. For
   direct-initialization, the permissible types for explicit conversion
@@ -816,40 +842,47 @@ resolution selects the constructor in two phases:
 In copy-list-initialization, if an explicit constructor is chosen, the
 initialization is ill-formed.
 [*Note 1*: This differs from other situations
-[[over.match.ctor]], [[over.match.copy]], where only converting
 constructors are considered for copy-initialization. This restriction
 only applies if this initialization is part of the final result of
 overload resolution. — *end note*]
 #### Class template argument deduction <a id="over.match.class.deduct">[[over.match.class.deduct]]</a>
 When resolving a placeholder for a deduced class type
-[[dcl.type.class.deduct]] where the *template-name* names a primary
-class template `C`, a set of functions and function templates, called
-the guides of `C`, is formed comprising:
 - If `C` is defined, for each constructor of `C`, a function template
   with the following properties:
   - The template parameters are the template parameters of `C` followed
     by the template parameters (including default template arguments) of
     the constructor, if any.
-  - The types of the function parameters are those of the constructor.
   - The return type is the class template specialization designated by
     `C` and template arguments corresponding to the template parameters
     of `C`.
 - If `C` is not defined or does not declare any constructors, an
   additional function template derived as above from a hypothetical
   constructor `C()`.
 - An additional function template derived as above from a hypothetical
   constructor `C(C)`, called the *copy deduction candidate*.
 - For each *deduction-guide*, a function or function template with the
   following properties:
-  - The template parameters, if any, and function parameters are those
-    of the *deduction-guide*.
   - The return type is the *simple-template-id* of the
     *deduction-guide*.
 In addition, if `C` is defined and its definition satisfies the
 conditions for an aggregate class [[dcl.init.aggr]] with the assumption
@@ -909,11 +942,11 @@ specialization whose template parameter list is that of `A` and whose
 template argument list is a specialization of `A` with the template
 argument list of `A` [[temp.dep.type]] having a member typedef `type`
 designating a template specialization with the template argument list of
 `A` but with `C` as the template.
-[*Note 1*: Equivalently, the template parameter list of the
 specialization is that of `C`, the template argument list of the
 specialization is `B`, and the member typedef names `C` with the
 template argument list of `C`. — *end note*]
 [*Example 1*:
@@ -966,12 +999,13 @@ J j = { "ghi" };    // error: cannot bind reference to array of unsigned char to
 ```
 — *end example*]
 When resolving a placeholder for a deduced class type
-[[dcl.type.simple]] where the *template-name* names an alias template
-`A`, the *defining-type-id* of `A` must be of the form
 ``` bnf
 typenameₒₚₜ nested-name-specifierₒₚₜ templateₒₚₜ simple-template-id
 ```
@@ -1211,15 +1245,76 @@ parameters to agree in number with the arguments in the list.
 - A candidate function having fewer than m parameters is viable only if
   it has an ellipsis in its parameter list [[dcl.fct]]. For the purposes
   of overload resolution, any argument for which there is no
   corresponding parameter is considered to “match the ellipsis”
   [[over.ics.ellipsis]].
-- A candidate function having more than m parameters is viable only if
- all parameters following the mᵗʰ have default arguments
- [[dcl.fct.default]]. For the purposes of overload resolution, the
- parameter list is truncated on the right, so that there are exactly m
-  parameters.
 Second, for a function to be viable, if it has associated constraints
 [[temp.constr.decl]], those constraints shall be satisfied
 [[temp.constr.constr]].
@@ -1250,14 +1345,14 @@ then
 - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
   ICSʲ(`F₂`), or, if not that,
 - the context is an initialization by user-defined conversion (see
   [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
-  standard conversion sequence from the return type of `F₁` to the
   destination type (i.e., the type of the entity being initialized) is a
   better conversion sequence than the standard conversion sequence from
-  the return type of `F₂` to the destination type
   \[*Example 1*:
   ``` cpp
   struct A {
     A();
     operator int();
@@ -1271,13 +1366,13 @@ then
   — *end example*]
   or, if not that,
 - the context is an initialization by conversion function for direct
   reference binding [[over.match.ref]] of a reference to function type,
-  the return type of `F1` is the same kind of reference (lvalue or
   rvalue) as the reference being initialized, and the return type of
-  `F2` is not
   \[*Example 2*:
   ``` cpp
   template <class T> struct A {
     operator T&();    // #1
     operator T&&();   // #2
@@ -1288,24 +1383,38 @@ then
   Fn&& rf = a;        // calls #2
   ```
   — *end example*]
   or, if not that,
-- `F1` is not a function template specialization and `F2` is a function
   template specialization, or, if not that,
-- `F1` and `F2` are function template specializations, and the function
-  template for `F1` is more specialized than the template for `F2`
   according to the partial ordering rules described in
   [[temp.func.order]], or, if not that,
-- `F1` and `F2` are non-template functions with the same
- parameter-type-lists, and `F1` is more constrained than `F2` according
- to the partial ordering of constraints described in
- [[temp.constr.order]], or if not that,
-- `F1` is a constructor for a class `D`, `F2` is a constructor for a
   base class `B` of `D`, and for all arguments the corresponding
-  parameters of `F1` and `F2` have the same type
-  \[*Example 3*:
   ``` cpp
   struct A {
     A(int = 0);
   };
@@ -1319,48 +1428,48 @@ then
   }
   ```
   — *end example*]
   or, if not that,
-- `F2` is a rewritten candidate [[over.match.oper]] and `F1` is not
-  \[*Example 4*:
   ``` cpp
   struct S {
     friend auto operator<=>(const S&, const S&) = default;        // #1
     friend bool operator<(const S&, const S&);                    // #2
   };
   bool b = S() < S();                                             // calls #2
   ```
   — *end example*]
   or, if not that,
-- `F1` and `F2` are rewritten candidates, and `F2` is a synthesized
-  candidate with reversed order of parameters and `F1` is not
-  \[*Example 5*:
   ``` cpp
   struct S {
     friend std::weak_ordering operator<=>(const S&, int);         // #1
     friend std::weak_ordering operator<=>(int, const S&);         // #2
   };
   bool b = 1 < S();                                               // calls #2
   ```
   — *end example*]
-  or, if not that
-- `F1` and `F2` are generated from class template argument deduction
-  [[over.match.class.deduct]] for a class `D`, and `F2` is generated
-  from inheriting constructors from a base class of `D` while `F1` is
   not, and for each explicit function argument, the corresponding
-  parameters of `F1` and `F2` are either both ellipses or have the same
   type, or, if not that,
-- `F1` is generated from a *deduction-guide* [[over.match.class.deduct]]
-  and `F2` is not, or, if not that,
-- `F1` is the copy deduction candidate [[over.match.class.deduct]] and
-  `F2` is not, or, if not that,
-- `F1` is generated from a non-template constructor and `F2` is
   generated from a constructor template.
-  \[*Example 6*:
   ``` cpp
   template <class T> struct A {
     using value_type = T;
     A(value_type);    // #1
     A(const A&);      // #2
@@ -1388,11 +1497,11 @@ then
 If there is exactly one viable function that is a better function than
 all other viable functions, then it is the one selected by overload
 resolution; otherwise the call is ill-formed.[^7]
-[*Example 7*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
@@ -1411,35 +1520,13 @@ void f() {
 }
 ```
 — *end example*]
-If the best viable function resolves to a function for which multiple
-declarations were found, and if any two of these declarations inhabit
-different scopes and specify a default argument that made the function
-viable, the program is ill-formed.
-[*Example 8*:
-``` cpp
-namespace A {
-  extern "C" void f(int = 5);
-}
-namespace B {
-  extern "C" void f(int = 5);
-}
-using A::f;
-using B::f;
-void use() {
-  f(3);             // OK, default argument was not used for viability
-  f();              // error: found default argument twice
-}
-```
-— *end example*]
 #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
 ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
@@ -1452,17 +1539,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]],
@@ -1519,40 +1606,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]].
@@ -1659,11 +1746,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
@@ -1675,34 +1762,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
@@ -1712,11 +1812,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
@@ -1739,16 +1839,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
@@ -1804,11 +1905,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);
@@ -2052,12 +2153,12 @@ conversion sequences unless one of the following rules applies:
     ```
     — *end example*]
     or, if not that,
   - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
-    binds an lvalue reference to a function lvalue and `S2` binds an
-    rvalue reference to a function lvalue
     \[*Example 4*:
     ``` cpp
     int f(void(&)());               // #1
     int f(void(&&)());              // #2
     void g();
@@ -2065,28 +2166,33 @@ conversion sequences unless one of the following rules applies:
     ```
     — *end example*]
     or, if not that,
   - `S1` and `S2` differ only in their qualification conversion
-    [[conv.qual]] and yield similar types `T1` and `T2`, respectively,
-    where `T1` can be converted to `T2` by a qualification conversion.
     \[*Example 5*:
     ``` cpp
     int f(const volatile int *);
     int f(const int *);
     int i;
     int j = f(&i);                  // calls f(const int*)
     ```
     — *end example*]
     or, if not that,
   - `S1`
-    and `S2` include reference bindings [[dcl.init.ref]], and the types
- to which the references refer are the same type except for top-level
- cv-qualifiers, and the type to which the reference initialized by
-    `S2` refers is more cv-qualified than the type to which the
-    reference initialized by `S1` refers.
     \[*Example 6*:
     ``` cpp
     int f(const int &);
     int f(int &);
     int g(const int &);
@@ -2102,20 +2208,51 @@ conversion sequences unless one of the following rules applies:
     };
     void g(const X& a, X b) {
       a.f();                        // calls X::f() const
       b.f();                        // calls X::f()
     }
     ```
     — *end example*]
 - User-defined conversion sequence `U1` is a better conversion sequence
   than another user-defined conversion sequence `U2` if they contain the
   same user-defined conversion function or constructor or they
   initialize the same class in an aggregate initialization and in either
   case the second standard conversion sequence of `U1` is better than
   the second standard conversion sequence of `U2`.
-  \[*Example 7*:
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
@@ -2143,11 +2280,11 @@ indistinguishable unless one of the following rules applies:
     to the rank of `FP2`, and
   - `T3` is not a floating-point type, or `T3` is a floating-point type
     whose rank is not equal to the rank of `FP1`, or the floating-point
     conversion subrank [[conv.rank]] of `FP2` is greater than the
     subrank of `T3`.
-    \[*Example 8*:
     ``` cpp
     int f(std::float32_t);
     int f(std::float64_t);
     int f(long long);
     float x;
@@ -2164,11 +2301,11 @@ indistinguishable unless one of the following rules applies:
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
   class `C` is derived directly or indirectly from `B`,
   - conversion of `C*` to `B*` is better than conversion of `C*` to
     `A*`,
-    \[*Example 9*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;
@@ -2199,29 +2336,31 @@ indistinguishable unless one of the following rules applies:
   [[over.match.best]]); in all other contexts, the source types will be
   the same and the target types will be different. — *end note*]
 ## Address of an overload set <a id="over.over">[[over.over]]</a>
-An *id-expression* whose terminal name refers to an overload set S and
-that appears without arguments is resolved to a function, a pointer to
-function, or a pointer to member function for a specific function that
-is chosen from a set of functions selected from S determined based on
-the target type required in the context (if any), as described below.
-The target can be
 - an object or reference being initialized
   [[dcl.init]], [[dcl.init.ref]], [[dcl.init.list]],
-- the left side of an assignment [[expr.ass]],
 - a parameter of a function [[expr.call]],
 - a parameter of a user-defined operator [[over.oper]],
 - the return value of a function, operator function, or conversion
   [[stmt.return]],
 - an explicit type conversion
   [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]], or
-- a non-type *template-parameter* [[temp.arg.nontype]].
-The *id-expression* can be preceded by the `&` operator.
 [*Note 1*: Any redundant set of parentheses surrounding the function
 name is ignored [[expr.prim.paren]]. — *end note*]
 If there is no target, all non-template functions named are selected.
@@ -2250,17 +2389,17 @@ All functions with associated constraints that are not satisfied
 [[temp.constr.decl]] are eliminated from the set of selected functions.
 If more than one function in the set remains, all function template
 specializations in the set are eliminated if the set also contains a
 function that is not a function template specialization. Any given
 non-template function `F0` is eliminated if the set contains a second
-non-template function that is more constrained than `F0` according to
-the partial ordering rules of [[temp.constr.order]]. Any given function
-template specialization `F1` is eliminated if the set contains a second
-function template specialization whose function template is more
-specialized than the function template of `F1` according to the partial
-ordering rules of  [[temp.func.order]]. After such eliminations, if any,
-there shall remain exactly one selected function.
 [*Example 1*:
 ``` cpp
 int f(double);
@@ -2274,12 +2413,15 @@ void g() {
   (int (*)(int))&f;             // cast expression as selector
 }
 ```
 The initialization of `pfe` is ill-formed because no `f()` with type
-`int(...)` has been declared, and not because of any ambiguity. For
-another example,
 ``` cpp
 struct X {
   int f(int);
   static int f(long);
@@ -2294,10 +2436,27 @@ int (X::*p5)(int)  = &(X::f);   // error: wrong syntax for
 int    (*p6)(long) = &(X::f);   // OK
 ```
 — *end example*]
 [*Note 4*: If `f` and `g` are both overload sets, the Cartesian product
 of possibilities is considered to resolve `f(&g)`, or the equivalent
 expression `f(g)`. — *end note*]
 [*Note 5*:
@@ -2331,10 +2490,11 @@ operator-function-id:
     operator operator
 ```
 ``` bnf
 %% Ed. note: character protrusion would misalign various operators.
 operator: one of
     'new delete new[] delete[] co_await ( ) [ ] -> ->*'
     '~ ! + - * / % ^ &'
     '| = += -= *= /= %= ^= &='
     '|= == != < > <= >= <=> &&'
@@ -2389,44 +2549,39 @@ explicitly stated in  [[basic.stc.dynamic]].
 The `co_await` operator is described completely in  [[expr.await]]. The
 attributes and restrictions found in the rest of [[over.oper]] do not
 apply to it unless explicitly stated in  [[expr.await]].
-An operator function shall either
-- be a member function or
-- be a non-member function that has at least one non-object parameter
-  whose type is a class, a reference to a class, an enumeration, or a
-  reference to an enumeration.
-It is not possible to change the precedence, grouping, or number of
-operands of operators. The meaning of the operators `=`, (unary) `&`,
-and `,` (comma), predefined for each type, can be changed for specific
-class types by defining operator functions that implement these
-operators. Likewise, the meaning of the operators (unary) `&` and `,`
-(comma) can be changed for specific enumeration types. Operator
-functions are inherited in the same manner as other base class
-functions.
 An operator function shall be a prefix unary, binary, function call,
 subscripting, class member access, increment, or decrement operator
 function.
 [*Note 3*: The identities among certain predefined operators applied to
-basic types (for example, `++a` ≡ `a+=1`) need not hold for operator
-functions. Some predefined operators, such as `+=`, require an operand
-to be an lvalue when applied to basic types; this is not required by
-operator functions. — *end note*]
 An operator function cannot have default arguments [[dcl.fct.default]],
 except where explicitly stated below. Operator functions cannot have
 more or fewer parameters than the number required for the corresponding
 operator, as described in the rest of [[over.oper]].
-Operators not mentioned explicitly in subclauses  [[over.ass]] through
-[[over.inc]] act as ordinary unary and binary operators obeying the
-rules of  [[over.unary]] or  [[over.binary]].
 ### Unary operators <a id="over.unary">[[over.unary]]</a>
 A *prefix unary operator function* is a function named `operator@` for a
 prefix *unary-operator* `@` [[expr.unary.op]] that is either a
@@ -2484,11 +2639,11 @@ function for a relational operator [[expr.rel]]. A
 three-way comparison operator [[expr.spaceship]]. A
 *comparison operator function* is an equality operator function, a
 relational operator function, or a three-way comparison operator
 function.
-#### Simple assignment <a id="over.ass">[[over.ass]]</a>
 A *simple assignment operator function* is a binary operator function
 named `operator=`. A simple assignment operator function shall be a
 non-static member function.
@@ -2816,12 +2971,13 @@ bool    operator>=(T, T);
 R       operator<=>(T, T);
 ```
 where `R` is the result type specified in [[expr.spaceship]].
-For every `T`, where `T` is a pointer-to-member type or
-`std::nullptr_t`, there exist candidate operator functions of the form
 ``` cpp
 bool operator==(T, T);
 bool operator!=(T, T);
 ```
@@ -2923,21 +3079,21 @@ T       operator?:(bool, T, T);
 ## User-defined literals <a id="over.literal">[[over.literal]]</a>
 ``` bnf
 literal-operator-id:
-    operator string-literal identifier
     operator user-defined-string-literal
 ```
-The *string-literal* or *user-defined-string-literal* in a
-*literal-operator-id* shall have no *encoding-prefix* and shall contain
-no characters other than the implicit terminating `'\0'`. The
-*ud-suffix* of the *user-defined-string-literal* or the *identifier* in
-a *literal-operator-id* is called a *literal suffix identifier*. The
-first form of *literal-operator-id* is deprecated [[depr.lit]]. Some
-literal suffix identifiers are reserved for future standardization; see
 [[usrlit.suffix]]. A declaration whose *literal-operator-id* uses such a
 literal suffix identifier is ill-formed, no diagnostic required.
 A declaration whose *declarator-id* is a *literal-operator-id* shall
 declare a function or function template that belongs to a namespace (it
@@ -2972,17 +3128,17 @@ is ill-formed.
 A *raw literal operator* is a literal operator with a single parameter
 whose type is `const char*`.
 A *numeric literal operator template* is a literal operator template
 whose *template-parameter-list* has a single *template-parameter* that
-is a non-type template parameter pack [[temp.variadic]] with element
 type `char`. A *string literal operator template* is a literal operator
-template whose *template-parameter-list* comprises a single non-type
-*template-parameter* of class type. The declaration of a literal
-operator template shall have an empty *parameter-declaration-clause* and
-shall declare either a numeric literal operator template or a string
-literal operator template.
 Literal operators and literal operator templates shall not have C
 language linkage.
 [*Note 1*: Literal operators and literal operator templates are usually
@@ -3057,35 +3213,37 @@ extern "C" void operator ""_m(long double);         // error: C language linkage
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.list]: dcl.md#dcl.init.list
 [dcl.init.ref]: dcl.md#dcl.init.ref
 [dcl.init.string]: dcl.md#dcl.init.string
 [dcl.type.class.deduct]: dcl.md#dcl.type.class.deduct
 [dcl.type.simple]: dcl.md#dcl.type.simple
 [depr.lit]: future.md#depr.lit
 [expr.arith.conv]: expr.md#expr.arith.conv
-[expr.ass]: expr.md#expr.ass
 [expr.await]: expr.md#expr.await
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.compound]: expr.md#expr.compound
 [expr.cond]: expr.md#expr.cond
 [expr.eq]: expr.md#expr.eq
 [expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.pre.incr]: expr.md#expr.pre.incr
 [expr.prim.paren]: expr.md#expr.prim.paren
 [expr.prim.this]: expr.md#expr.prim.this
 [expr.rel]: expr.md#expr.rel
 [expr.spaceship]: expr.md#expr.spaceship
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.unary.op]: expr.md#expr.unary.op
 [lex.ext]: lex.md#lex.ext
 [namespace.udecl]: dcl.md#namespace.udecl
 [over]: #over
-[over.ass]: #over.ass
 [over.best.ics]: #over.best.ics
 [over.best.ics.general]: #over.best.ics.general
 [over.binary]: #over.binary
 [over.binary.general]: #over.binary.general
 [over.built]: #over.built

 [*Note 1*: Each of two or more entities with the same name in the same
 scope, which must be functions or function templates, is commonly called
 an “overload”. — *end note*]
+When a function is designated in a call, which function declaration is
+being referenced and the validity of the call are determined by
+comparing the types of the arguments at the point of use with the types
+of the parameters in the declarations in the overload set. This function
 selection process is called *overload resolution* and is defined in
 [[over.match]].
+[*Note 2*: Overload sets are formed by *id-expression*s naming
+functions and function templates and by *splice-expression*s designating
+entities of the same kinds. — *end note*]
 [*Example 1*:
 ``` cpp
 double abs(double);
 int abs(int);
 - “lvalue reference to cv `X`” for functions declared without a
   *ref-qualifier* or with the `&` *ref-qualifier*
 - “rvalue reference to cv `X`” for functions declared with the `&&`
   *ref-qualifier*
+where `X` is the class of which the function is a direct member and cv
+is the cv-qualification on the member function declaration.
 [*Example 1*: For a `const` member function of class `X`, the extra
 parameter is assumed to have type “lvalue reference to
 `const X`”. — *end example*]
 member function, the program is ill-formed.
 [*Note 2*: The resolution of the address of an overload set in other
 contexts is described in [[over.over]]. — *end note*]
+##### Call to designated function <a id="over.call.func">[[over.call.func]]</a>
 Of interest in  [[over.call.func]] are only those function calls in
+which the *postfix-expression* ultimately contains an *id-expression* or
+*splice-expression* that designates one or more functions. Such a
+*postfix-expression*, perhaps nested arbitrarily deep in parentheses,
+has one of the following forms:
 ``` bnf
 postfix-expression:
     postfix-expression '.' id-expression
+    postfix-expression '.' splice-expression
     postfix-expression '->' id-expression
+ postfix-expression '->' splice-expression
+    id-expression
+    splice-expression
 ```
 These represent two syntactic subcategories of function calls: qualified
 function calls and unqualified function calls.
+In qualified function calls, the function is designated by an
+*id-expression* or *splice-expression* E preceded by an `->` or `.`
+operator. Since the construct `A->B` is generally equivalent to
+`(*A).B`, the rest of [[over]] assumes, without loss of generality, that
+all member function calls have been normalized to the form that uses an
+object and the `.` operator. Furthermore, [[over]] assumes that the
+*postfix-expression* that is the left operand of the `.` operator has
+type “cv `T`” where `T` denotes a class.[^2]
+The set of candidate functions either is the set found by name lookup
+[[class.member.lookup]] if E is an *id-expression* or is the set
+determined as specified in  [[expr.prim.splice]] if E is a
+*splice-expression*. The argument list is the *expression-list* in the
+call augmented by the addition of the left operand of the `.` operator
+in the normalized member function call as the implied object argument
+[[over.match.funcs]].
+In unqualified function calls, the function is designated by an
+*id-expression* or a *splice-expression* E. The set of candidate
+functions either is the set found by name lookup [[basic.lookup]] if E
+is an *id-expression* or is the set determined as specified in
+[[expr.prim.splice]] if E is a *splice-expression*. The set of candidate
+functions consists either entirely of non-member functions or entirely
+of member functions of some class `T`. In the former case or if E is
+either a *splice-expression* or the address of an overload set, the
+argument list is the same as the *expression-list* in the call.
+Otherwise, the argument list is the *expression-list* in the call
+augmented by the addition of an implied object argument as in a
+qualified function call. If the current class is, or is derived from,
+`T`, and the keyword `this` [[expr.prim.this]] refers to it,
+- if the unqualified function call appears in a precondition assertion
+  of a constructor or a postcondition assertion of a destructor and
+  overload resolution selects a non-static member function, the call is
+  ill-formed;
+- otherwise, the implied object argument is `(*this)`.
+Otherwise,
+- if overload resolution selects a non-static member function, the call
+  is ill-formed;
+- otherwise, a contrived object of type `T` becomes the implied object
+  argument.[^3]
 [*Example 1*:
 ``` cpp
 struct C {
+ bool a();
   void b() {
     a();                // OK, (*this).a()
   }
   void c(this const C&);    // #1
   void k(this int);
   operator int() const;
   void m(this const C& c) {
     c.k();              // OK
   }
+  C()
+    pre(a())            // error: implied this in constructor precondition
+    pre(this->a())      // OK
+    post(a());          // OK
+  ~C()
+    pre(a())            // OK
+    post(a())           // error: implied this in destructor postcondition
+    post(this->a());    // OK
 };
 ```
 — *end example*]
 returning `R`”, a *surrogate call function* with the unique name
 *call-function* and having the form
 ``` bnf
 'R' *call-function* '(' conversion-type-id \ %
+'F, P₁ a₁, …, Pₙ aₙ)' '{' return 'F (a₁, …, aₙ); }'
 ```
 is also considered as a candidate function. Similarly, surrogate call
 functions are added to the set of candidate functions for each
 non-explicit conversion function declared in a base class of `T`
 built-in operator [[expr.compound]].
 **Table: Relationship between operator and function call notation** <a id="over.match.oper">[over.match.oper]</a>
 | Subclause       | Expression | As member function  | As non-member function |
+| --------------- | ---------- | ------------------- | ---------------------- |
 | (a)}            |
 | (a, b)}         |
+| [[over.assign]] | `a=b`      | `(a).operator= (b)` |                        |
 | [[over.sub]]    | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]]    | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}         |
 bool d1 = 0 == D();             // OK, calls reversed #4; #5 does not forbid #4 as a rewrite target
 ```
 — *end example*]
+For the first parameter of the built-in assignment operators, only
+standard conversion sequences [[over.ics.scs]] are considered.
 For all other operators, no such restrictions apply.
 The set of candidate functions for overload resolution for some operator
 `@` is the union of the member candidates, the non-member candidates,
 When objects of class type are direct-initialized [[dcl.init]],
 copy-initialized from an expression of the same or a derived class type
 [[dcl.init]], or default-initialized [[dcl.init]], overload resolution
 selects the constructor. For direct-initialization or
+default-initialization (including default-initialization in the context
+of copy-list-initialization), the candidate functions are all the
+constructors of the class of the object being initialized. Otherwise,
+the candidate functions are all the non-explicit constructors
+[[class.conv.ctor]] of that class. The argument list is the
+*expression-list* or *assignment-expression* of the *initializer*. For
+default-initialization in the context of copy-list-initialization, if an
+explicit constructor is chosen, the initialization is ill-formed.
 #### Copy-initialization of class by user-defined conversion <a id="over.match.copy">[[over.match.copy]]</a>
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
 corresponding non-reference copy-initialization. — *end note*]
 Assuming that “*cv1* `T`” is the type of the object being initialized,
 with `T` a class type, the candidate functions are selected as follows:
+- The non-explicit constructors [[class.conv.ctor]] of `T` are candidate
   functions.
 - When the type of the initializer expression is a class type “cv `S`”,
   conversion functions are considered. The permissible types for
   non-explicit conversion functions are `T` and any class derived from
   `T`. When initializing a temporary object [[class.mem]] to be bound to
 conversion function to be invoked. Assuming that “reference to *cv1*
 `T`” is the type of the reference being initialized, the candidate
 functions are selected as follows:
 - Let R be a set of types including
+  - “lvalue reference to *cv2* `T2`” (when converting to an lvalue) and
+  - “*cv2* `T2`” and “rvalue reference to *cv2* `T2`” (when converting
+    to an rvalue or an lvalue of function type)
   for any `T2`. The permissible types for non-explicit conversion
   functions are the members of R where “*cv1* `T`” is
   reference-compatible [[dcl.init.ref]] with “*cv2* `T2`”. For
   direct-initialization, the permissible types for explicit conversion
 In copy-list-initialization, if an explicit constructor is chosen, the
 initialization is ill-formed.
 [*Note 1*: This differs from other situations
+[[over.match.ctor]], [[over.match.copy]], where only non-explicit
 constructors are considered for copy-initialization. This restriction
 only applies if this initialization is part of the final result of
 overload resolution. — *end note*]
 #### Class template argument deduction <a id="over.match.class.deduct">[[over.match.class.deduct]]</a>
 When resolving a placeholder for a deduced class type
+[[dcl.type.class.deduct]] where the *template-name* or
+*splice-type-specifier* designates a primary class template `C`, a set
+of functions and function templates, called the guides of `C`, is formed
+comprising:
 - If `C` is defined, for each constructor of `C`, a function template
   with the following properties:
   - The template parameters are the template parameters of `C` followed
     by the template parameters (including default template arguments) of
     the constructor, if any.
+  - The associated constraints [[temp.constr.decl]] are the conjunction
+    of the associated constraints of `C` and the associated constraints
+    of the constructor, if any. \[*Note 1*: A *constraint-expression* in
+    the *template-head* of `C` is checked for satisfaction before any
+    constraints from the *template-head* or trailing *requires-clause*
+    of the constructor. — *end note*]
+  - The *parameter-declaration-clause* is that of the constructor.
   - The return type is the class template specialization designated by
     `C` and template arguments corresponding to the template parameters
     of `C`.
 - If `C` is not defined or does not declare any constructors, an
   additional function template derived as above from a hypothetical
   constructor `C()`.
 - An additional function template derived as above from a hypothetical
   constructor `C(C)`, called the *copy deduction candidate*.
 - For each *deduction-guide*, a function or function template with the
   following properties:
+  - The *template-head*, if any, and *parameter-declaration-clause* are
+ those of the *deduction-guide*.
   - The return type is the *simple-template-id* of the
     *deduction-guide*.
 In addition, if `C` is defined and its definition satisfies the
 conditions for an aggregate class [[dcl.init.aggr]] with the assumption
 template argument list is a specialization of `A` with the template
 argument list of `A` [[temp.dep.type]] having a member typedef `type`
 designating a template specialization with the template argument list of
 `A` but with `C` as the template.
+[*Note 2*: Equivalently, the template parameter list of the
 specialization is that of `C`, the template argument list of the
 specialization is `B`, and the member typedef names `C` with the
 template argument list of `C`. — *end note*]
 [*Example 1*:
 ```
 — *end example*]
 When resolving a placeholder for a deduced class type
+[[dcl.type.simple]] where the *template-name* or *splice-type-specifier*
+designates an alias template `A`, the *defining-type-id* of `A` must be
+of the form
 ``` bnf
 typenameₒₚₜ nested-name-specifierₒₚₜ templateₒₚₜ simple-template-id
 ```
 - A candidate function having fewer than m parameters is viable only if
   it has an ellipsis in its parameter list [[dcl.fct]]. For the purposes
   of overload resolution, any argument for which there is no
   corresponding parameter is considered to “match the ellipsis”
   [[over.ics.ellipsis]].
+- A candidate function `C` having more than m parameters is viable only
+ if the set of scopes G, as defined below, is not empty. G consists of
+ every scope X that satisfies all of the following:
+ - There is a declaration of `C`, whose host scope is X, considered by
+    the overload resolution.
+  - For every $k^\textrm{th}$ parameter P where k \> m, there is a
+    reachable declaration, whose host scope is X, that specifies a
+    default argument [[dcl.fct.default]] for P.
+  If `C` is selected as the best viable function [[over.match.best]]:
+  - G shall contain exactly one scope (call it S).
+  - If the candidates are denoted by a *splice-expression*, then S shall
+    not be a block scope.
+  - The default arguments used in the call to `C` are the default
+    arguments specified by the reachable declarations whose host scope
+    is S.
+  For the purposes of overload resolution, the parameter list is
+  truncated on the right, so that there are exactly m parameters.
+[*Example 1*:
+``` cpp
+namespace A {
+  extern "C" void f(int, int = 5);
+  extern "C" void f(int = 6, int);
+}
+namespace B {
+  extern "C" void f(int, int = 7);
+}
+void use() {
+  [:^^A::f:](3, 4);     // OK, default argument was not used for viability
+  [:^^A::f:](3);        // error: default argument provided by declarations from two scopes
+  [:^^A::f:]();         // OK, default arguments provided by declarations in the scope of A
+  using A::f;
+  using B::f;
+  f(3, 4);              // OK, default argument was not used for viability
+  f(3);                 // error: default argument provided by declaration from two scopes
+  f();                  // OK, default arguments provided by declarations in the scope of A
+  void g(int = 8);
+  g();                  // OK
+  [:^^g:]();            // error: host scope is block scope
+}
+void h(int = 7);
+constexpr std::meta::info r = ^^h;
+void poison() {
+  void h(int = 8);
+  h();                  // OK, calls h(8)
+  [:^^h:]();            // error: default argument provided by declarations from two scopes
+}
+void call_h() {
+  [:^^h:]();            // error: default argument provided by declarations from two scopes
+  [:r:]();              // error: default argument provided by declarations from two scopes
+}
+template<typename... Ts>
+int k(int = 3, Ts...);
+int i = k<int>();       // error: no default argument for the second parameter
+int j = k<>();          // OK
+```
+— *end example*]
 Second, for a function to be viable, if it has associated constraints
 [[temp.constr.decl]], those constraints shall be satisfied
 [[temp.constr.constr]].
 - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
   ICSʲ(`F₂`), or, if not that,
 - the context is an initialization by user-defined conversion (see
   [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
+  standard conversion sequence from the result of `F₁` to the
   destination type (i.e., the type of the entity being initialized) is a
   better conversion sequence than the standard conversion sequence from
+  the result of `F₂` to the destination type
   \[*Example 1*:
   ``` cpp
   struct A {
     A();
     operator int();
   — *end example*]
   or, if not that,
 - the context is an initialization by conversion function for direct
   reference binding [[over.match.ref]] of a reference to function type,
+  the return type of `F₁` is the same kind of reference (lvalue or
   rvalue) as the reference being initialized, and the return type of
+  `F₂` is not
   \[*Example 2*:
   ``` cpp
   template <class T> struct A {
     operator T&();    // #1
     operator T&&();   // #2
   Fn&& rf = a;        // calls #2
   ```
   — *end example*]
   or, if not that,
+- `F₁` is not a function template specialization and `F₂` is a function
   template specialization, or, if not that,
+- `F₁` and `F₂` are function template specializations, and the function
+  template for `F₁` is more specialized than the template for `F₂`
   according to the partial ordering rules described in
   [[temp.func.order]], or, if not that,
+- `F₁` and `F₂` are non-template functions and `F₁` is more
+ partial-ordering-constrained than `F₂` [[temp.constr.order]]
+ \[*Example 3*:
+ ``` cpp
+  template <typename T = int>
+  struct S {
+    constexpr void f();                       // #1
+    constexpr void f(this S&) requires true;  // #2
+  };
+  void test() {
+    S<> s;
+    s.f();                // calls #2
+  }
+  ```
+  — *end example*]
+  or, if not that,
+- `F₁` is a constructor for a class `D`, `F₂` is a constructor for a
   base class `B` of `D`, and for all arguments the corresponding
+  parameters of `F₁` and `F₂` have the same type
+  \[*Example 4*:
   ``` cpp
   struct A {
     A(int = 0);
   };
   }
   ```
   — *end example*]
   or, if not that,
+- `F₂` is a rewritten candidate [[over.match.oper]] and `F₁` is not
+  \[*Example 5*:
   ``` cpp
   struct S {
     friend auto operator<=>(const S&, const S&) = default;        // #1
     friend bool operator<(const S&, const S&);                    // #2
   };
   bool b = S() < S();                                             // calls #2
   ```
   — *end example*]
   or, if not that,
+- `F₁` and `F₂` are rewritten candidates, and `F₂` is a synthesized
+  candidate with reversed order of parameters and `F₁` is not
+  \[*Example 6*:
   ``` cpp
   struct S {
     friend std::weak_ordering operator<=>(const S&, int);         // #1
     friend std::weak_ordering operator<=>(int, const S&);         // #2
   };
   bool b = 1 < S();                                               // calls #2
   ```
   — *end example*]
+  or, if not that,
+- `F₁` and `F₂` are generated from class template argument deduction
+  [[over.match.class.deduct]] for a class `D`, and `F₂` is generated
+  from inheriting constructors from a base class of `D` while `F₁` is
   not, and for each explicit function argument, the corresponding
+  parameters of `F₁` and `F₂` are either both ellipses or have the same
   type, or, if not that,
+- `F₁` is generated from a *deduction-guide* [[over.match.class.deduct]]
+  and `F₂` is not, or, if not that,
+- `F₁` is the copy deduction candidate [[over.match.class.deduct]] and
+  `F₂` is not, or, if not that,
+- `F₁` is generated from a non-template constructor and `F₂` is
   generated from a constructor template.
+  \[*Example 7*:
   ``` cpp
   template <class T> struct A {
     using value_type = T;
     A(value_type);    // #1
     A(const A&);      // #2
 If there is exactly one viable function that is a better function than
 all other viable functions, then it is the one selected by overload
 resolution; otherwise the call is ill-formed.[^7]
+[*Example 8*:
 ``` cpp
 void Fcn(const int*,  short);
 void Fcn(int*, int);
 }
 ```
 — *end example*]
+[*Note 1*: If the best viable function was made viable by one or more
+default arguments, additional requirements apply
+[[over.match.viable]]. — *end note*]
 #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
 ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
 Implicit conversion sequences are concerned only with the type,
 cv-qualification, and value category of the argument and how these are
 converted to match the corresponding properties of the parameter.
+[*Note 1*: Other properties, such as the lifetime, storage duration,
+linkage, alignment, accessibility of the argument, whether the argument
+is a bit-field, and whether a function is deleted
+[[dcl.fct.def.delete]], are ignored. So, although an implicit conversion
+sequence can be defined for a given argument-parameter pair, the
+conversion from the argument to the parameter might still be ill-formed
+in the final analysis. — *end note*]
 A well-formed implicit conversion sequence is one of the following
 forms:
 - a standard conversion sequence [[over.ics.scs]],
 [*Note 3*: When the parameter has a class type, this is a conceptual
 conversion defined for the purposes of [[over]]; the actual
 initialization is defined in terms of constructors and is not a
 conversion. — *end note*]
+When the cv-unqualified version of the type of the argument expression
+is the same as the parameter type, the implicit conversion sequence is
+an identity conversion. When the parameter has a class type and the
+argument expression has a (possibly cv-qualified) derived class type,
+the implicit conversion sequence is a derived-to-base conversion from
+the derived class to the base class. A derived-to-base conversion has
+Conversion rank [[over.ics.scs]].
 [*Note 4*: There is no such standard conversion; this derived-to-base
 conversion exists only in the description of implicit conversion
 sequences. — *end note*]
+[*Example 2*: An implicit conversion sequence from an argument of type
+`const A` to a parameter of type `A` can be formed, even if overload
+resolution for copy-initialization of `A` from the argument would not
+find a viable function [[over.match.ctor]], [[over.match.viable]]. The
+implicit conversion sequence for that case is the identity sequence; it
+contains no “conversion” from `const A` to `A`. — *end example*]
 When the parameter is the implicit object parameter of a static member
 function, the implicit conversion sequence is a standard conversion
 sequence that is neither better nor worse than any other standard
 conversion sequence.
 In all contexts, when converting to the implicit object parameter or
 when converting to the left operand of an assignment operation only
 standard conversion sequences are allowed.
+[*Note 5*: When a conversion to the explicit object parameter occurs,
+it can include user-defined conversion sequences. — *end note*]
 If no conversions are required to match an argument to a parameter type,
 the implicit conversion sequence is the standard conversion sequence
 consisting of the identity conversion [[over.ics.scs]].
 when selecting the best user-defined conversion for a user-defined
 conversion sequence (see  [[over.match.best]] and  [[over.best.ics]]).
 If the user-defined conversion is specified by a specialization of a
 conversion function template, the second standard conversion sequence
+shall have Exact Match rank.
 A conversion of an expression of class type to the same class type is
 given Exact Match rank, and a conversion of an expression of class type
 to a base class of that type is given Conversion rank, in spite of the
 fact that a constructor (i.e., a user-defined conversion function) is
 call is matched with the ellipsis parameter specification of the
 function called (see  [[expr.call]]).
 ##### Reference binding <a id="over.ics.ref">[[over.ics.ref]]</a>
+When a parameter of type “reference to cv `T`” binds directly
+[[dcl.init.ref]] to an argument expression:
+- If the argument expression has a type that is a derived class of the
+  parameter type, the implicit conversion sequence is a derived-to-base
+  conversion [[over.best.ics]].
+- Otherwise, if the type of the argument is possibly cv-qualified `T`,
+  or if `T` is an array type of unknown bound with element type `U` and
+  the argument has an array type of known bound whose element type is
+  possibly cv-qualified `U`, the implicit conversion sequence is the
+  identity conversion.
+- Otherwise, if `T` is a function type, the implicit conversion sequence
+  is a function pointer conversion.
+- Otherwise, the implicit conversion sequence is a qualification
+  conversion.
 [*Example 4*:
 ``` cpp
 struct A {};
 struct B : public A {} b;
 int f(A&);
 int f(B&);
 int i = f(b);       // calls f(B&), an exact match, rather than f(A&), a conversion
+void g() noexcept;
+int h(void (&)() noexcept); // #1
+int h(void (&)());          // #2
+int j = h(g);               // calls #1, an exact match, rather than #2, a function pointer conversion
 ```
 — *end example*]
 If the parameter binds directly to the result of applying a conversion
 function to the argument expression, the implicit conversion sequence is
 a user-defined conversion sequence [[over.ics.user]] whose second
+standard conversion sequence is determined by the above rules.
 When a parameter of reference type is not bound directly to an argument
 expression, the conversion sequence is the one required to convert the
 argument expression to the referenced type according to
 [[over.best.ics]]. Conceptually, this conversion sequence corresponds to
 Except for an implicit object parameter, for which see
 [[over.match.funcs]], an implicit conversion sequence cannot be formed
 if it requires binding an lvalue reference other than a reference to a
 non-volatile `const` type to an rvalue or binding an rvalue reference to
+an lvalue of object type.
 [*Note 9*: This means, for example, that a candidate function cannot be
 a viable function if it has a non-`const` lvalue reference parameter
 (other than the implicit object parameter) and the corresponding
 argument would require a temporary to be created to initialize the
 When an argument is an initializer list [[dcl.init.list]], it is not an
 expression and special rules apply for converting it to a parameter
 type.
+If the initializer list is a *designated-initializer-list* and the
+parameter is not a reference, a conversion is only possible if the
+parameter has an aggregate type that can be initialized from the
+initializer list according to the rules for aggregate initialization
+[[dcl.init.aggr]], in which case the implicit conversion sequence is a
+user-defined conversion sequence whose second standard conversion
+sequence is an identity conversion.
 [*Note 10*:
 Aggregate initialization does not require that the members are declared
 in designation order. If, after overload resolution, the order does not
 f( {'a','b'} );                 // OK, f(initializer_list<int>) integral promotion
 f( {1.0} );                     // error: narrowing
 struct A {
   A(std::initializer_list<double>);                     // #1
+  A(std::initializer_list<std::complex<double>>); // #2
   A(std::initializer_list<std::string>);                // #3
 };
 A a{ 1.0,2.0 };                 // OK, uses #1
 void g(A);
     ```
     — *end example*]
     or, if not that,
   - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
+    binds an lvalue reference to an lvalue of function type and `S2`
+ binds an rvalue reference to an lvalue of function type
     \[*Example 4*:
     ``` cpp
     int f(void(&)());               // #1
     int f(void(&&)());              // #2
     void g();
     ```
     — *end example*]
     or, if not that,
   - `S1` and `S2` differ only in their qualification conversion
+    [[conv.qual]] and yield similar types `T1` and `T2`, respectively
+ (where a standard conversion sequence that is a reference binding is
+    considered to yield the cv-unqualified referenced type), where `T1`
+    and `T2` are not the same type, and `const T2` is
+    reference-compatible with `T1` [[dcl.init.ref]]
     \[*Example 5*:
     ``` cpp
     int f(const volatile int *);
     int f(const int *);
     int i;
     int j = f(&i);                  // calls f(const int*)
+    int g(const int*);
+    int g(const volatile int* const&);
+    int* p;
+    int k = g(p);                   // calls g(const int*)
     ```
     — *end example*]
     or, if not that,
   - `S1`
+    and `S2` bind “reference to `T1`” and “reference to `T2`”,
+ respectively [[dcl.init.ref]], where `T1` and `T2` are not the same
+ type, and `T2` is reference-compatible with `T1`
     \[*Example 6*:
     ``` cpp
     int f(const int &);
     int f(int &);
     int g(const int &);
     };
     void g(const X& a, X b) {
       a.f();                        // calls X::f() const
       b.f();                        // calls X::f()
     }
+    int h(int (&)[]);
+    int h(int (&)[1]);
+    void g2() {
+      int a[1];
+      h(a);                         // calls h(int (&)[1])
+    }
+    ```
+    — *end example*]
+    or, if not that,
+  - `S1` and `S2` bind the same reference type “reference to `T`” and
+    have source types `V1` and `V2`, respectively, where the standard
+    conversion sequence from `V1*` to `T*` is better than the standard
+    conversion sequence from `V2*` to `T*`.
+    \[*Example 7*:
+    ``` cpp
+    struct Z {};
+    struct A {
+      operator Z&();
+      operator const Z&();          // #1
+    };
+    struct B {
+      operator Z();
+      operator const Z&&();         // #2
+    };
+    const Z& r1 = A();              // OK, uses #1
+    const Z&& r2 = B();             // OK, uses #2
     ```
     — *end example*]
 - User-defined conversion sequence `U1` is a better conversion sequence
   than another user-defined conversion sequence `U2` if they contain the
   same user-defined conversion function or constructor or they
   initialize the same class in an aggregate initialization and in either
   case the second standard conversion sequence of `U1` is better than
   the second standard conversion sequence of `U2`.
+  \[*Example 8*:
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
     to the rank of `FP2`, and
   - `T3` is not a floating-point type, or `T3` is a floating-point type
     whose rank is not equal to the rank of `FP1`, or the floating-point
     conversion subrank [[conv.rank]] of `FP2` is greater than the
     subrank of `T3`.
+    \[*Example 9*:
     ``` cpp
     int f(std::float32_t);
     int f(std::float64_t);
     int f(long long);
     float x;
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
   class `C` is derived directly or indirectly from `B`,
   - conversion of `C*` to `B*` is better than conversion of `C*` to
     `A*`,
+    \[*Example 10*:
     ``` cpp
     struct A {};
     struct B : public A {};
     struct C : public B {};
     C* pc;
   [[over.match.best]]); in all other contexts, the source types will be
   the same and the target types will be different. — *end note*]
 ## Address of an overload set <a id="over.over">[[over.over]]</a>
+An expression that designates an overload set S and that appears without
+arguments is resolved to a function, a pointer to function, or a pointer
+to member function for a specific function that is chosen from a set of
+functions selected from S determined based on the target type required
+in the context (if any), as described below. The target can be
 - an object or reference being initialized
   [[dcl.init]], [[dcl.init.ref]], [[dcl.init.list]],
+- the left side of an assignment [[expr.assign]],
 - a parameter of a function [[expr.call]],
 - a parameter of a user-defined operator [[over.oper]],
 - the return value of a function, operator function, or conversion
   [[stmt.return]],
 - an explicit type conversion
   [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]], or
+- a constant template parameter [[temp.arg.nontype]].
+If the target type contains a placeholder type, placeholder type
+deduction is performed [[dcl.type.auto.deduct]], and the remainder of
+this subclause uses the target type so deduced. The expression can be
+preceded by the `&` operator.
 [*Note 1*: Any redundant set of parentheses surrounding the function
 name is ignored [[expr.prim.paren]]. — *end note*]
 If there is no target, all non-template functions named are selected.
 [[temp.constr.decl]] are eliminated from the set of selected functions.
 If more than one function in the set remains, all function template
 specializations in the set are eliminated if the set also contains a
 function that is not a function template specialization. Any given
 non-template function `F0` is eliminated if the set contains a second
+non-template function that is more partial-ordering-constrained than
+`F0` [[temp.constr.order]]. Any given function template specialization
+`F1` is eliminated if the set contains a second function template
+specialization whose function template is more specialized than the
+function template of `F1` according to the partial ordering rules of
+[[temp.func.order]]. After such eliminations, if any, there shall remain
+exactly one selected function.
 [*Example 1*:
 ``` cpp
 int f(double);
   (int (*)(int))&f;             // cast expression as selector
 }
 ```
 The initialization of `pfe` is ill-formed because no `f()` with type
+`int(...)` has been declared, and not because of any ambiguity.
+— *end example*]
+[*Example 2*:
 ``` cpp
 struct X {
   int f(int);
   static int f(long);
 int    (*p6)(long) = &(X::f);   // OK
 ```
 — *end example*]
+[*Example 3*:
+``` cpp
+template<bool B> struct X {
+  void f(short) requires B;
+  void f(long);
+  template<typename> void g(short) requires B;
+  template<typename> void g(long);
+};
+void test() {
+  &X<true>::f;                  // error: ambiguous; constraints are not considered
+  &X<true>::g<int>;             // error: ambiguous; constraints are not considered
+}
+```
+— *end example*]
 [*Note 4*: If `f` and `g` are both overload sets, the Cartesian product
 of possibilities is considered to resolve `f(&g)`, or the equivalent
 expression `f(g)`. — *end note*]
 [*Note 5*:
     operator operator
 ```
 ``` bnf
 %% Ed. note: character protrusion would misalign various operators.
 operator: one of
     'new delete new[] delete[] co_await ( ) [ ] -> ->*'
     '~ ! + - * / % ^ &'
     '| = += -= *= /= %= ^= &='
     '|= == != < > <= >= <=> &&'
 The `co_await` operator is described completely in  [[expr.await]]. The
 attributes and restrictions found in the rest of [[over.oper]] do not
 apply to it unless explicitly stated in  [[expr.await]].
+An operator function shall have at least one function parameter or
+implicit object parameter whose type is a class, a reference to a class,
+an enumeration, or a reference to an enumeration. It is not possible to
+change the precedence, grouping, or number of operands of operators. The
+meaning of the operators `=`, (unary) `&`, and `,` (comma), predefined
+for each type, can be changed for specific class types by defining
+operator functions that implement these operators. Likewise, the meaning
+of the operators (unary) `&` and `,` (comma) can be changed for specific
+enumeration types. Operator functions are inherited in the same manner
+as other base class functions.
 An operator function shall be a prefix unary, binary, function call,
 subscripting, class member access, increment, or decrement operator
 function.
 [*Note 3*: The identities among certain predefined operators applied to
+fundamental types (for example, `++a` ≡ `a+=1`) need not hold for
+operator functions. Some predefined operators, such as `+=`, require an
+operand to be an lvalue when applied to fundamental types; this is not
+required by operator functions. — *end note*]
 An operator function cannot have default arguments [[dcl.fct.default]],
 except where explicitly stated below. Operator functions cannot have
 more or fewer parameters than the number required for the corresponding
 operator, as described in the rest of [[over.oper]].
+Operators not mentioned explicitly in subclauses  [[over.assign]]
+through  [[over.inc]] act as ordinary unary and binary operators obeying
+the rules of  [[over.unary]] or  [[over.binary]].
 ### Unary operators <a id="over.unary">[[over.unary]]</a>
 A *prefix unary operator function* is a function named `operator@` for a
 prefix *unary-operator* `@` [[expr.unary.op]] that is either a
 three-way comparison operator [[expr.spaceship]]. A
 *comparison operator function* is an equality operator function, a
 relational operator function, or a three-way comparison operator
 function.
+#### Simple assignment <a id="over.assign">[[over.assign]]</a>
 A *simple assignment operator function* is a binary operator function
 named `operator=`. A simple assignment operator function shall be a
 non-static member function.
 R       operator<=>(T, T);
 ```
 where `R` is the result type specified in [[expr.spaceship]].
+For every `T`, where `T` is a pointer-to-member type, `std::meta::info`,
+or `std::nullptr_t`, there exist candidate operator functions of the
+form
 ``` cpp
 bool operator==(T, T);
 bool operator!=(T, T);
 ```
 ## User-defined literals <a id="over.literal">[[over.literal]]</a>
 ``` bnf
 literal-operator-id:
+    operator unevaluated-string identifier
     operator user-defined-string-literal
 ```
+The *user-defined-string-literal* in a *literal-operator-id* shall have
+no *encoding-prefix*. The *unevaluated-string* or
+*user-defined-string-literal* shall be empty. The *ud-suffix* of the
+*user-defined-string-literal* or the *identifier* in a
+*literal-operator-id* is called a *literal suffix identifier*. The first
+form of *literal-operator-id* is deprecated [[depr.lit]]. Some literal
+suffix identifiers are reserved for future standardization; see
 [[usrlit.suffix]]. A declaration whose *literal-operator-id* uses such a
 literal suffix identifier is ill-formed, no diagnostic required.
 A declaration whose *declarator-id* is a *literal-operator-id* shall
 declare a function or function template that belongs to a namespace (it
 A *raw literal operator* is a literal operator with a single parameter
 whose type is `const char*`.
 A *numeric literal operator template* is a literal operator template
 whose *template-parameter-list* has a single *template-parameter* that
+is a constant template parameter pack [[temp.variadic]] with element
 type `char`. A *string literal operator template* is a literal operator
+template whose *template-parameter-list* comprises a single
+*parameter-declaration* that declares a constant template parameter of
+class type. The declaration of a literal operator template shall have an
+empty *parameter-declaration-clause* and shall declare either a numeric
+literal operator template or a string literal operator template.
 Literal operators and literal operator templates shall not have C
 language linkage.
 [*Note 1*: Literal operators and literal operator templates are usually
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.list]: dcl.md#dcl.init.list
 [dcl.init.ref]: dcl.md#dcl.init.ref
 [dcl.init.string]: dcl.md#dcl.init.string
+[dcl.type.auto.deduct]: dcl.md#dcl.type.auto.deduct
 [dcl.type.class.deduct]: dcl.md#dcl.type.class.deduct
 [dcl.type.simple]: dcl.md#dcl.type.simple
 [depr.lit]: future.md#depr.lit
 [expr.arith.conv]: expr.md#expr.arith.conv
+[expr.assign]: expr.md#expr.assign
 [expr.await]: expr.md#expr.await
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.compound]: expr.md#expr.compound
 [expr.cond]: expr.md#expr.cond
 [expr.eq]: expr.md#expr.eq
 [expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.pre.incr]: expr.md#expr.pre.incr
 [expr.prim.paren]: expr.md#expr.prim.paren
+[expr.prim.splice]: expr.md#expr.prim.splice
 [expr.prim.this]: expr.md#expr.prim.this
 [expr.rel]: expr.md#expr.rel
 [expr.spaceship]: expr.md#expr.spaceship
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.unary.op]: expr.md#expr.unary.op
 [lex.ext]: lex.md#lex.ext
 [namespace.udecl]: dcl.md#namespace.udecl
 [over]: #over
+[over.assign]: #over.assign
 [over.best.ics]: #over.best.ics
 [over.best.ics.general]: #over.best.ics.general
 [over.binary]: #over.binary
 [over.binary.general]: #over.binary.general
 [over.built]: #over.built

Diff to HTML by rtfpessoa