From Jason Turner

[over.match.funcs.general]

C++20 → C++23 6.9 KB 165 lines
Current Draft | LaTeX Source
Archived: C++20 | C++23
Markdown: C++20 | C++23
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpmdw6fv5d/{from.md → to.md} +162 -0
tmp/tmpmdw6fv5d/{from.md → to.md} RENAMED
@@ -0,0 +1,162 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ #### General <a id="over.match.funcs.general">[[over.match.funcs.general]]</a>
2
+
3
+ The subclauses of  [[over.match.funcs]] describe the set of candidate
4
+ functions and the argument list submitted to overload resolution in each
5
+ context in which overload resolution is used. The source transformations
6
+ and constructions defined in these subclauses are only for the purpose
7
+ of describing the overload resolution process. An implementation is not
8
+ required to use such transformations and constructions.
9
+
10
+ The set of candidate functions can contain both member and non-member
11
+ functions to be resolved against the same argument list. If a member
12
+ function is
13
+
14
+ - an implicit object member function that is not a constructor, or
15
+ - a static member function and the argument list includes an implied
16
+ object argument,
17
+
18
+ it is considered to have an extra first parameter, called the
19
+ *implicit object parameter*, which represents the object for which the
20
+ member function has been called.
21
+
22
+ Similarly, when appropriate, the context can construct an argument list
23
+ that contains an *implied object argument* as the first argument in the
24
+ list to denote the object to be operated on.
25
+
26
+ For implicit object member functions, the type of the implicit object
27
+ parameter is
28
+
29
+ - “lvalue reference to cv `X`” for functions declared without a
30
+ *ref-qualifier* or with the `&` *ref-qualifier*
31
+ - “rvalue reference to cv `X`” for functions declared with the `&&`
32
+ *ref-qualifier*
33
+
34
+ where `X` is the class of which the function is a member and cv is the
35
+ cv-qualification on the member function declaration.
36
+
37
+ [*Example 1*: For a `const` member function of class `X`, the extra
38
+ parameter is assumed to have type “lvalue reference to
39
+ `const X`”. — *end example*]
40
+
41
+ For conversion functions that are implicit object member functions, the
42
+ function is considered to be a member of the class of the implied object
43
+ argument for the purpose of defining the type of the implicit object
44
+ parameter. For non-conversion functions that are implicit object member
45
+ functions nominated by a *using-declaration* in a derived class, the
46
+ function is considered to be a member of the derived class for the
47
+ purpose of defining the type of the implicit object parameter. For
48
+ static member functions, the implicit object parameter is considered to
49
+ match any object (since if the function is selected, the object is
50
+ discarded).
51
+
52
+ [*Note 1*: No actual type is established for the implicit object
53
+ parameter of a static member function, and no attempt will be made to
54
+ determine a conversion sequence for that parameter
55
+ [[over.match.best]]. — *end note*]
56
+
57
+ During overload resolution, the implied object argument is
58
+ indistinguishable from other arguments. The implicit object parameter,
59
+ however, retains its identity since no user-defined conversions can be
60
+ applied to achieve a type match with it. For implicit object member
61
+ functions declared without a *ref-qualifier*, even if the implicit
62
+ object parameter is not const-qualified, an rvalue can be bound to the
63
+ parameter as long as in all other respects the argument can be converted
64
+ to the type of the implicit object parameter.
65
+
66
+ [*Note 2*: The fact that such an argument is an rvalue does not affect
67
+ the ranking of implicit conversion sequences
68
+ [[over.ics.rank]]. — *end note*]
69
+
70
+ Because other than in list-initialization only one user-defined
71
+ conversion is allowed in an implicit conversion sequence, special rules
72
+ apply when selecting the best user-defined conversion
73
+ [[over.match.best]], [[over.best.ics]].
74
+
75
+ [*Example 2*:
76
+
77
+ ``` cpp
78
+ class T {
79
+ public:
80
+ T();
81
+ };
82
+
83
+ class C : T {
84
+ public:
85
+ C(int);
86
+ };
87
+ T a = 1; // error: no viable conversion (T(C(1)) not considered)
88
+ ```
89
+
90
+ — *end example*]
91
+
92
+ In each case where conversion functions of a class `S` are considered
93
+ for initializing an object or reference of type `T`, the candidate
94
+ functions include the result of a search for the
95
+ *conversion-function-id* `operator T` in `S`.
96
+
97
+ [*Note 3*: This search can find a specialization of a conversion
98
+ function template [[basic.lookup]]. — *end note*]
99
+
100
+ Each such case also defines sets of *permissible types* for explicit and
101
+ non-explicit conversion functions; each (non-template) conversion
102
+ function that
103
+
104
+ - is a non-hidden member of `S`,
105
+ - yields a permissible type, and,
106
+ - for the former set, is non-explicit
107
+
108
+ is also a candidate function. If initializing an object, for any
109
+ permissible type cv `U`, any *cv2* `U`, *cv2* `U&`, or *cv2* `U&&` is
110
+ also a permissible type. If the set of permissible types for explicit
111
+ conversion functions is empty, any candidates that are explicit are
112
+ discarded.
113
+
114
+ In each case where a candidate is a function template, candidate
115
+ function template specializations are generated using template argument
116
+ deduction [[temp.over]], [[temp.deduct]]. If a constructor template or
117
+ conversion function template has an *explicit-specifier* whose
118
+ *constant-expression* is value-dependent [[temp.dep]], template argument
119
+ deduction is performed first and then, if the context admits only
120
+ candidates that are not explicit and the generated specialization is
121
+ explicit [[dcl.fct.spec]], it will be removed from the candidate set.
122
+ Those candidates are then handled as candidate functions in the usual
123
+ way.[^1]
124
+
125
+ A given name can refer to, or a conversion can consider, one or more
126
+ function templates as well as a set of non-template functions. In such a
127
+ case, the candidate functions generated from each function template are
128
+ combined with the set of non-template candidate functions.
129
+
130
+ A defaulted move special member function
131
+ [[class.copy.ctor]], [[class.copy.assign]] that is defined as deleted is
132
+ excluded from the set of candidate functions in all contexts. A
133
+ constructor inherited from class type `C` [[class.inhctor.init]] that
134
+ has a first parameter of type “reference to *cv1* `P`” (including such a
135
+ constructor instantiated from a template) is excluded from the set of
136
+ candidate functions when constructing an object of type *cv2* `D` if the
137
+ argument list has exactly one argument and `C` is reference-related to
138
+ `P` and `P` is reference-related to `D`.
139
+
140
+ [*Example 3*:
141
+
142
+ ``` cpp
143
+ struct A {
144
+ A(); // #1
145
+ A(A &&); // #2
146
+ template<typename T> A(T &&); // #3
147
+ };
148
+ struct B : A {
149
+ using A::A;
150
+ B(const B &); // #4
151
+ B(B &&) = default; // #5, implicitly deleted
152
+
153
+ struct X { X(X &&) = delete; } x;
154
+ };
155
+ extern B b1;
156
+ B b2 = static_cast<B&&>(b1); // calls #4: #1 is not viable, #2, #3, and #5 are not candidates
157
+ struct C { operator B&&(); };
158
+ B b3 = C(); // calls #4
159
+ ```
160
+
161
+ — *end example*]
162
+