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

Files changed (1) hide show

tmp/tmp1tmbt6mn/{from.md → to.md} +466 -181

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

@@ -1,30 +1,26 @@
 ### Candidate functions and argument lists <a id="over.match.funcs">[[over.match.funcs]]</a>
 The subclauses of  [[over.match.funcs]] describe the set of candidate
 functions and the argument list submitted to overload resolution in each
-of the seven contexts in which overload resolution is used. The source
-transformations and constructions defined in these subclauses are only
-for the purpose of describing the overload resolution process. An
-implementation is not required to use such transformations and
-constructions.
 The set of candidate functions can contain both member and non-member
 functions to be resolved against the same argument list. So that
 argument and parameter lists are comparable within this heterogeneous
-set, a member function is considered to have an extra parameter, called
-the *implicit object parameter*, which represents the object for which
-the member function has been called. For the purposes of overload
 resolution, both static and non-static member functions have an implicit
 object parameter, but constructors do not.
 Similarly, when appropriate, the context can construct an argument list
-that contains an *implied object argument* to denote the object to be
-operated on. Since arguments and parameters are associated by position
-within their respective lists, the convention is that the implicit
-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
@@ -48,25 +44,25 @@ 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]]).
@@ -81,46 +77,80 @@ public:
 class C : T {
 public:
   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
-non-template functions. In such a case, the candidate functions
-generated from each function template are combined with the set of
-non-template candidate functions.
-A defaulted move constructor or assignment operator ([[class.copy]])
-that is defined as deleted is excluded from the set of candidate
-functions in all contexts.
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
-In a function call ([[expr.call]])
 ``` bnf
 postfix-expression '(' expression-listₒₚₜ ')'
 ```
-if the *postfix-expression* denotes a set of overloaded functions and/or
-function templates, overload resolution is applied as specified in
 [[over.call.func]]. If the *postfix-expression* denotes an object of
 class type, overload resolution is applied as specified in
 [[over.call.object]].
-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>
@@ -142,82 +172,75 @@ These represent two syntactic subcategories of function calls: qualified
 function calls and unqualified function calls.
 In qualified function calls, the name to be resolved is an
 *id-expression* and is preceded by an `->` or `.` operator. Since the
 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
-the implied object argument ([[over.match.funcs]]).
 In unqualified function calls, the name is not qualified by an `->` or
 `.` operator and has the more general form of a *primary-expression*.
 The name is looked up in the context of the function call following the
-normal rules for name lookup in function calls ([[basic.lookup]]). The
 function declarations found by that lookup constitute the set of
 candidate functions. Because of the rules for name lookup, the set of
 candidate functions consists (1) entirely of non-member functions or (2)
 entirely of member functions of some class `T`. In case (1), the
 argument list is the same as the *expression-list* in the call. In case
 (2), 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 keyword `this` ([[class.this]]) is in scope and refers to
 class `T`, or a derived class of `T`, then the implied object argument
 is `(*this)`. If the keyword `this` is not in scope or refers to another
 class, then a contrived object of type `T` becomes the implied object
-argument[^4]. If the argument list is augmented by a contrived object
 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ₒₚₜ 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`
 provided the function is not hidden within `T` by another intervening
-declaration[^5].
-If such a surrogate call function is selected by overload resolution,
-the corresponding conversion function will be called to convert `E` to
-the appropriate function pointer or reference, and the function will
-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)`.
@@ -249,18 +272,18 @@ int i = a(1);                   // calls f1 via pointer returned from conversion
 #### 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 {
@@ -269,11 +292,12 @@ struct String {
   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.
 }
 ```
@@ -284,16 +308,16 @@ 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)}      |
@@ -301,25 +325,24 @@ for the built-in operator (Clause  [[expr]]).
 | [[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
-whose cv-unqualified version is `T2`, three sets of candidate functions,
-designated *member candidates*, *non-member candidates* and *built-in
-candidates*, are constructed as follows:
 - If `T1` is a complete class type or a class currently being defined,
   the set of member candidates is the result of the qualified lookup of
-  `T1::operator@` ([[over.call.func]]); otherwise, the set of member
   candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
-  the usual rules for name lookup in unqualified function calls (
-  [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   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
@@ -332,26 +355,48 @@ candidates*, are constructed as follows:
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
   - do not have the same parameter-type-list as any non-member candidate
     that is not a function template specialization.
 For the built-in assignment operators, conversions of the left operand
 are restricted as follows:
 - no temporaries are introduced to hold the left operand, and
 - 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 is the union of
-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]
 [*Example 2*:
 ``` cpp
 struct A {
@@ -364,17 +409,36 @@ void m() {
 }
 ```
 — *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 {
@@ -396,14 +460,14 @@ The second operand of operator `->` is ignored in selecting an
 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:
@@ -426,19 +490,20 @@ void B::f() {
 — *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
@@ -452,25 +517,25 @@ 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
@@ -489,120 +554,226 @@ 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
-  standard conversion sequence ([[over.ics.scs]]) are candidate
- functions. For direct-initialization, those explicit conversion
- functions that are not hidden within `S` and yield type `T` or a type
- that can be converted to type `T` with a qualification conversion (
- [[conv.qual]]) are also candidate functions. Conversion functions that
- return a cv-qualified type are considered to yield the cv-unqualified
- version of that type for this process of selecting candidate
- functions. Conversion functions that return “reference to *cv2* `X`”
- 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
- resolution is performed again, where the candidate functions are all
-  the constructors of the class `T` and the argument list consists of
- 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 {
@@ -630,9 +801,123 @@ 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*]

 ### Candidate functions and argument lists <a id="over.match.funcs">[[over.match.funcs]]</a>
 The subclauses of  [[over.match.funcs]] describe the set of candidate
 functions and the argument list submitted to overload resolution in each
+context in which overload resolution is used. The source transformations
+and constructions defined in these subclauses are only for the purpose
+of describing the overload resolution process. An implementation is not
+required to use such transformations and constructions.
 The set of candidate functions can contain both member and non-member
 functions to be resolved against the same argument list. So that
 argument and parameter lists are comparable within this heterogeneous
+set, a member function is considered to have an extra first parameter,
+called the *implicit object parameter*, which represents the object for
+which the member function has been called. For the purposes of overload
 resolution, both static and non-static member functions have an implicit
 object parameter, but constructors do not.
 Similarly, when appropriate, the context can construct an argument list
+that contains an *implied object argument* as the first argument in the
+list to denote the object to be operated on.
 For non-static member functions, the type of the implicit object
 parameter is
 - “lvalue reference to cv `X`” for functions declared without a
 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*, 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]]).
 class C : T {
 public:
   C(int);
 };
+T a = 1;            // error: no viable conversion (T(C(1)) not considered)
 ```
 — *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]]). If a constructor template
+or conversion function template has an *explicit-specifier* whose
+*constant-expression* is value-dependent [[temp.dep]], template argument
+deduction is performed first and then, if the context requires a
+candidate that is not explicit and the generated specialization is
+explicit [[dcl.fct.spec]], it will be removed from the candidate set.
+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 non-template functions. In such a case, the candidate
+functions generated from each function template are combined with the
+set of non-template candidate functions.
+A defaulted move special member function ([[class.copy.ctor]],
+[[class.copy.assign]]) that is defined as deleted is excluded from the
+set of candidate functions in all contexts. A constructor inherited from
+class type `C` [[class.inhctor.init]] that has a first parameter of type
+“reference to *cv1* `P`” (including such a constructor instantiated from
+a template) is excluded from the set of candidate functions when
+constructing an object of type *cv2* `D` if the argument list has
+exactly one argument and `C` is reference-related to `P` and `P` is
+reference-related to `D`.
+[*Example 3*:
+``` cpp
+struct A {
+  A();                                  // #1
+  A(A &&);                              // #2
+  template<typename T> A(T &&);         // #3
+};
+struct B : A {
+  using A::A;
+  B(const B &);                         // #4
+  B(B &&) = default;                    // #5, implicitly deleted
+  struct X { X(X &&) = delete; } x;
+};
+extern B b1;
+B b2 = static_cast<B&&>(b1);            // calls #4: #1 is not viable, #2, #3, and #5 are not candidates
+struct C { operator B&&(); };
+B b3 = C();                             // calls #4
+```
+— *end example*]
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
+In a function call [[expr.call]]
 ``` bnf
 postfix-expression '(' expression-listₒₚₜ ')'
 ```
+if the *postfix-expression* names at least one function or function
+template, overload resolution is applied as specified in
 [[over.call.func]]. If the *postfix-expression* denotes an object of
 class type, overload resolution is applied as specified in
 [[over.call.object]].
+If the *postfix-expression* is the address of an overload set, 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>
 function calls and unqualified function calls.
 In qualified function calls, the name to be resolved is an
 *id-expression* and is 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.[^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 the implied object argument
+[[over.match.funcs]].
 In unqualified function calls, the name is not qualified by an `->` or
 `.` operator and has the more general form of a *primary-expression*.
 The name is looked up in the context of the function call following the
+normal rules for name lookup in expressions [[basic.lookup]]. The
 function declarations found by that lookup constitute the set of
 candidate functions. Because of the rules for name lookup, the set of
 candidate functions consists (1) entirely of non-member functions or (2)
 entirely of member functions of some class `T`. In case (1), the
 argument list is the same as the *expression-list* in the call. In case
 (2), 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 keyword `this` [[class.this]] is in scope and refers to
 class `T`, or a derived class of `T`, then the implied object argument
 is `(*this)`. If the keyword `this` is not in scope or refers to another
 class, then a contrived object of type `T` becomes the implied object
+argument.[^4] If the argument list is augmented by a contrived object
 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 *postfix-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-seqₒₚₜ ref-qualifierₒₚₜ noexcept-specifierₒₚₜ attribute-specifier-seqₒₚₜ ';'
 ```
+where the optional *cv-qualifier-seq* 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`
 provided the function is not hidden within `T` by another intervening
+declaration.[^5]
 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)`.
 #### 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 [[expr.compound]].
 [*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
+operators are always built-in operators interpreted according to
+[[expr.compound]]. `?:` 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 {
   operator const char* ();
 };
 String operator + (const String&, const String&);
 void f() {
+ const char* p= "one" + "two"; // error: cannot add two pointers; overloaded operator+ not considered
+                                // 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.
 }
 ```
 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 [[over.match.oper]] (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 [[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.sub]] | `a[b]`     | `(a).operator[](b)` |                        |
 | [[over.ref]] | `a->`      | `(a).operator->( )` |                        |
 | (a, 0)}      |
+For a unary operator `@` with an operand of type *cv1* `T1`, and for a
+binary operator `@` with a left operand of type *cv1* `T1` and a right
+operand of type *cv2* `T2`, four sets of candidate functions, designated
+*member candidates*, *non-member candidates*, *built-in candidates*, and
+*rewritten candidates*, are constructed as follows:
 - If `T1` is a complete class type or a class currently being defined,
   the set of member candidates is the result of the qualified lookup of
+  `T1::operator@` [[over.call.func]]; otherwise, the set of member
   candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
+  the usual rules for name lookup in unqualified function calls
+  [[basic.lookup.argdep]] except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   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
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
   - do not have the same parameter-type-list as any non-member candidate
     that is not a function template specialization.
+- The rewritten candidate set is determined as follows:
+  - For the relational [[expr.rel]] operators, the rewritten candidates
+    include all non-rewritten candidates for the expression `x <=> y`.
+  - For the relational [[expr.rel]] and three-way comparison
+    [[expr.spaceship]] operators, the rewritten candidates also include
+    a synthesized candidate, with the order of the two parameters
+    reversed, for each non-rewritten candidate for the expression
+    `y <=> x`.
+  - For the `!=` operator [[expr.eq]], the rewritten candidates include
+    all non-rewritten candidates for the expression `x == y`.
+  - For the equality operators, the rewritten candidates also include a
+    synthesized candidate, with the order of the two parameters
+    reversed, for each non-rewritten candidate for the expression
+    `y == x`.
+  - For all other operators, the rewritten candidate set is empty.
+  \[*Note 2*: A candidate synthesized from a member candidate has its
+  implicit object parameter as the second parameter, thus implicit
+  conversions are considered for the first, but not for the second,
+  parameter. — *end note*]
 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,
+the built-in candidates, and the rewritten candidates for that operator
+`@`.
+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 {
 }
 ```
 — *end example*]
+If a rewritten `operator<=>` candidate is selected by overload
+resolution for an operator `@`, `x @ y` is interpreted as
+`0 @ (y <=> x)` if the selected candidate is a synthesized candidate
+with reversed order of parameters, or `(x <=> y) @ 0` otherwise, using
+the selected rewritten `operator<=>` candidate. Rewritten candidates for
+the operator `@` are not considered in the context of the resulting
+expression.
+If a rewritten `operator==` candidate is selected by overload resolution
+for an operator `@`, its return type shall be cv `bool`, and `x @ y` is
+interpreted as:
+- if `@` is `!=` and the selected candidate is a synthesized candidate
+  with reversed order of parameters, `!(y == x)`,
+- otherwise, if `@` is `!=`, `!(x == y)`,
+- otherwise (when `@` is `==`), `y == x`,
+in each case using the selected rewritten `operator==` candidate.
 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
+[[expr.compound]].
 [*Example 3*:
 ``` cpp
 struct X {
 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
+[[expr.compound]].
+[*Note 3*:
 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:
 — *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
+(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
 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 object [[class.mem]] to be
+ bound to the first parameter of a constructor where the parameter is
+ of type “reference to *cv2* `T`” and the constructor is called with a
   single argument in the context of direct-initialization of an object
+  of type “*cv3* `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. A call to a conversion function
+ returning “reference to `X`” is a glvalue of type `X`, and such a
+ conversion function is 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
 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
+  standard conversion sequence [[over.ics.scs]] are candidate functions.
+  For direct-initialization, those explicit conversion functions that
+  are not hidden within `S` and yield type `T` or a type that can be
+  converted to type `T` with a qualification conversion [[conv.qual]]
+  are also candidate functions. Conversion functions that return a
+  cv-qualified type are considered to yield the cv-unqualified version
+  of that type for this process of selecting candidate functions. A call
+ to a conversion function returning “reference to `X`” is a glvalue of
+ type `X`, and such a conversion function is 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 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`” (when initializing an lvalue reference or an
+ rvalue reference to function) or “rvalue reference to *cv2* `T2`”
+ (when initializing an rvalue reference or an lvalue reference to
+ function), 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 subclause or when forming a
+list-initialization sequence according to [[over.ics.list]], overload
+resolution selects the constructor in two phases:
+- If the initializer list is not empty or `T` has no default
+ constructor, overload resolution is first performed where 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.
+- Otherwise, or if no viable initializer-list constructor is found,
+ overload resolution is performed again, where the candidate functions
+  are all the constructors of the class `T` and the argument list
+  consists of the elements of the initializer list.
+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
+that any dependent base class has no virtual functions and no virtual
+base classes, and the initializer is a non-empty *braced-init-list* or
+parenthesized *expression-list*, and there are no *deduction-guide*s for
+`C`, the set contains an additional function template, called the
+*aggregate deduction candidate*, defined as follows. Let x₁, …, xₙ be
+the elements of the *initializer-list* or *designated-initializer-list*
+of the *braced-init-list*, or of the *expression-list*. For each xᵢ, let
+eᵢ be the corresponding aggregate element of `C` or of one of its
+(possibly recursive) subaggregates that would be initialized by xᵢ
+[[dcl.init.aggr]] if
+- brace elision is not considered for any aggregate element that has a
+  dependent non-array type or an array type with a value-dependent
+  bound, and
+- each non-trailing aggregate element that is a pack expansion is
+  assumed to correspond to no elements of the initializer list, and
+- a trailing aggregate element that is a pack expansion is assumed to
+  correspond to all remaining elements of the initializer list (if any).
+If there is no such aggregate element eᵢ for any xᵢ, the aggregate
+deduction candidate is not added to the set. The aggregate deduction
+candidate is derived as above from a hypothetical constructor
+`C`(`T₁`, …, `Tₙ`), where
+- if eᵢ is of array type and xᵢ is a *braced-init-list* or
+  *string-literal*, `Tᵢ` is an rvalue reference to the declared type of
+  eᵢ, and
+- otherwise, `Tᵢ` is the declared type of eᵢ,
+except that additional parameter packs of the form `Pⱼ` `...` are
+inserted into the parameter list in their original aggregate element
+position corresponding to each non-trailing aggregate element of type
+`Pⱼ` that was skipped because it was a parameter pack, and the trailing
+sequence of parameters corresponding to a trailing aggregate element
+that is a pack expansion (if any) is replaced by a single parameter of
+the form `Tₙ` `...`.
+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
+```
+as specified in [[dcl.type.simple]]. The guides of `A` are the set of
+functions or function templates formed as follows. For each function or
+function template `f` in the guides of the template named by the
+*simple-template-id* of the *defining-type-id*, the template arguments
+of the return type of `f` are deduced from the *defining-type-id* of `A`
+according to the process in [[temp.deduct.type]] with the exception that
+deduction does not fail if not all template arguments are deduced. Let
+`g` denote the result of substituting these deductions into `f`. If
+substitution succeeds, form a function or function template `f'` with
+the following properties and add it to the set of guides of `A`:
+- The function type of `f'` is the function type of `g`.
+- If `f` is a function template, `f'` is a function template whose
+  template parameter list consists of all the template parameters of `A`
+  (including their default template arguments) that appear in the above
+  deductions or (recursively) in their default template arguments,
+  followed by the template parameters of `f` that were not deduced
+  (including their default template arguments), otherwise `f'` is not a
+  function template.
+- The associated constraints [[temp.constr.decl]] are the conjunction of
+  the associated constraints of `g` and a constraint that is satisfied
+  if and only if the arguments of `A` are deducible (see below) from the
+  return type.
+- If `f` is a copy deduction candidate [[over.match.class.deduct]], then
+  `f'` is considered to be so as well.
+- If `f` was generated from a *deduction-guide*
+  [[over.match.class.deduct]], then `f'` is considered to be so as well.
+- The *explicit-specifier* of `f'` is the *explicit-specifier* of `g`
+  (if any).
+The arguments of a template `A` are said to be deducible from a type `T`
+if, given a class template
+``` cpp
+template <typename> class AA;
+```
+with a single partial 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]], `AA<T>`
+matches the partial specialization.
 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 guides
+of the template named by the placeholder 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. The following exceptions
+apply:
+- The first phase in [[over.match.list]] (considering initializer-list
+  constructors) is omitted if the initializer list consists of a single
+  expression of type cv `U`, where `U` is, or is derived from, a
+  specialization of the class template directly or indirectly named by
+  the placeholder.
+- During template argument deduction for the aggregate deduction
+  candidate, the number of elements in a trailing parameter pack is only
+  deduced from the number of remaining function arguments if it is not
+  otherwise deduced.
+If the function or function template was generated from a constructor or
+*deduction-guide* that had an *explicit-specifier*, each such notional
+constructor is considered to have that same *explicit-specifier*. All
+such notional constructors are considered to be public members of the
+hypothetical class type.
 [*Example 1*:
 ``` cpp
 template <class T> struct A {
   template <class U> using TA = T;
   template <class U> B(U, TA<U>);
 };
 B b{(int*)0, (char*)0};         // OK, deduces B<char*>
+template <typename T>
+struct S {
+  T x;
+  T y;
+};
+template <typename T>
+struct C {
+  S<T> s;
+  T t;
+};
+template <typename T>
+struct D {
+  S<int> s;
+  T t;
+};
+C c1 = {1, 2};                  // error: deduction failed
+C c2 = {1, 2, 3};               // error: deduction failed
+C c3 = {{1u, 2u}, 3};           // OK, deduces C<int>
+D d1 = {1, 2};                  // error: deduction failed
+D d2 = {1, 2, 3};               // OK, braces elided, deduces D<int>
+template <typename T>
+struct E {
+  T t;
+  decltype(t) t2;
+};
+E e1 = {1, 2};                  // OK, deduces E<int>
+template <typename... T>
+struct Types {};
+template <typename... T>
+struct F : Types<T...>, T... {};
+struct X {};
+struct Y {};
+struct Z {};
+struct W { operator Y(); };
+F f1 = {Types<X, Y, Z>{}, {}, {}};      // OK, F<X, Y, Z> deduced
+F f2 = {Types<X, Y, Z>{}, X{}, Y{}};    // OK, F<X, Y, Z> deduced
+F f3 = {Types<X, Y, Z>{}, X{}, W{}};    // error: conflicting types deduced; operator Y not considered
+```
+— *end example*]
+[*Example 2*:
+``` cpp
+template <class T, class U> struct C {
+  C(T, U);                                      // #1
+};
+template<class T, class U>
+  C(T, U) -> C<T, std::type_identity_t<U>>;     // #2
+template<class V> using A = C<V *, V *>;
+template<std::integral W> using B = A<W>;
+int i{};
+double d{};
+A a1(&i, &i);   // deduces A<int>
+A a2(i, i);     // error: cannot deduce V * from i
+A a3(&i, &d);   // error: #1: cannot deduce (V*, V*) from (int *, double *)
+                // #2: cannot deduce A<V> from C<int *, double *>
+B b1(&i, &i);   // deduces B<int>
+B b2(&d, &d);   // error: cannot deduce B<W> from C<double *, double *>
+```
+Possible exposition-only implementation of the above procedure:
+``` cpp
+// The following concept ensures a specialization of A is deduced.
+template <class> class AA;
+template <class V> class AA<A<V>> { };
+template <class T> concept deduces_A = requires { sizeof(AA<T>); };
+// f1 is formed from the constructor #1 of C, generating the following function template
+template<T, U>
+  auto f1(T, U) -> C<T, U>;
+// Deducing arguments for C<T, U> from C<V *, V*> deduces T as V * and U as V *;
+// f1' is obtained by transforming f1 as described by the above procedure.
+template<class V> requires deduces_A<C<V *, V *>>
+  auto f1_prime(V *, V*) -> C<V *, V *>;
+// f2 is formed from the deduction-guide #2 of C
+template<class T, class U> auto f2(T, U) -> C<T, std::type_identity_t<U>>;
+// Deducing arguments for C<T, std::type_identity_t<U>> from C<V *, V*> deduces T as V *;
+// f2' is obtained by transforming f2 as described by the above procedure.
+template<class V, class U>
+  requires deduces_A<C<V *, std::type_identity_t<U>>>
+  auto f2_prime(V *, U) -> C<V *, std::type_identity_t<U>>;
+// The following concept ensures a specialization of B is deduced.
+template <class> class BB;
+template <class V> class BB<B<V>> { };
+template <class T> concept deduces_B = requires { sizeof(BB<T>); };
+// The guides for B derived from the above f1' and f2' for A are as follows:
+template<std::integral W>
+  requires deduces_A<C<W *, W *>> && deduces_B<C<W *, W *>>
+  auto f1_prime_for_B(W *, W *) -> C<W *, W *>;
+template<std::integral W, class U>
+  requires deduces_A<C<W *, std::type_identity_t<U>>> &&
+    deduces_B<C<W *, std::type_identity_t<U>>>
+  auto f2_prime_for_B(W *, U) -> C<W *, std::type_identity_t<U>>;
 ```
 — *end example*]

Diff to HTML by rtfpessoa