From Jason Turner

[over.match.oper]

C++17 → C++20 10.2 KB 118 lines
Current Draft | LaTeX Source
Archived: C++17 | C++20
Markdown: C++17 | C++20
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp8ske0w2p/{from.md → to.md} +75 -34
tmp/tmp8ske0w2p/{from.md → to.md} RENAMED
@@ -1,17 +1,17 @@
1
  #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
2
 
3
  If no operand of an operator in an expression has a type that is a class
4
  or an enumeration, the operator is assumed to be a built-in operator and
5
- interpreted according to Clause  [[expr]].
6
 
7
  [*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
8
- operators are always built-in operators interpreted according to Clause 
9
- [[expr]]. `?:` cannot be overloaded, but the rules in this subclause are
10
- used to determine the conversions to be applied to the second and third
11
- operands when they have class or enumeration type (
12
- [[expr.cond]]). — *end note*]
13
 
14
  [*Example 1*:
15
 
16
  ``` cpp
17
  struct String {
@@ -20,11 +20,12 @@ struct String {
20
  operator const char* ();
21
  };
22
  String operator + (const String&, const String&);
23
 
24
  void f() {
25
- const char* p= "one" + "two"; // ill-formed because neither operand has class or enumeration type
 
26
  int I = 1 + 1; // always evaluates to 2 even if class or enumeration types exist
27
  // that would perform the operation.
28
  }
29
  ```
30
 
@@ -35,16 +36,16 @@ user-defined operator function might be declared that implements this
35
  operator or a user-defined conversion can be necessary to convert the
36
  operand to a type that is appropriate for a built-in operator. In this
37
  case, overload resolution is used to determine which operator function
38
  or built-in operator is to be invoked to implement the operator.
39
  Therefore, the operator notation is first transformed to the equivalent
40
- function-call notation as summarized in Table  [[tab:over.rel.op.func]]
41
- (where `@` denotes one of the operators covered in the specified
42
- subclause). However, the operands are sequenced in the order prescribed
43
- for the built-in operator (Clause  [[expr]]).
44
 
45
- **Table: Relationship between operator and function call notation** <a id="tab:over.rel.op.func">[tab:over.rel.op.func]</a>
46
 
47
  | Subclause | Expression | As member function | As non-member function |
48
  | ------------ | ---------- | ------------------- | ---------------------- |
49
  | (a)} |
50
  | (a, b)} |
@@ -52,25 +53,24 @@ for the built-in operator (Clause  [[expr]]).
52
  | [[over.sub]] | `a[b]` | `(a).operator[](b)` | |
53
  | [[over.ref]] | `a->` | `(a).operator->( )` | |
54
  | (a, 0)} |
55
 
56
 
57
- For a unary operator `@` with an operand of a type whose cv-unqualified
58
- version is `T1`, and for a binary operator `@` with a left operand of a
59
- type whose cv-unqualified version is `T1` and a right operand of a type
60
- whose cv-unqualified version is `T2`, three sets of candidate functions,
61
- designated *member candidates*, *non-member candidates* and *built-in
62
- candidates*, are constructed as follows:
63
 
64
  - If `T1` is a complete class type or a class currently being defined,
65
  the set of member candidates is the result of the qualified lookup of
66
- `T1::operator@` ([[over.call.func]]); otherwise, the set of member
67
  candidates is empty.
68
  - The set of non-member candidates is the result of the unqualified
69
  lookup of `operator@` in the context of the expression according to
70
- the usual rules for name lookup in unqualified function calls (
71
- [[basic.lookup.argdep]]) except that all member functions are ignored.
72
  However, if no operand has a class type, only those non-member
73
  functions in the lookup set that have a first parameter of type `T1`
74
  or “reference to cv `T1`”, when `T1` is an enumeration type, or (if
75
  there is a right operand) a second parameter of type `T2` or
76
  “reference to cv `T2`”, when `T2` is an enumeration type, are
@@ -83,26 +83,48 @@ candidates*, are constructed as follows:
83
  - accept the same number of operands, and
84
  - accept operand types to which the given operand or operands can be
85
  converted according to [[over.best.ics]], and
86
  - do not have the same parameter-type-list as any non-member candidate
87
  that is not a function template specialization.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88
 
89
  For the built-in assignment operators, conversions of the left operand
90
  are restricted as follows:
91
 
92
  - no temporaries are introduced to hold the left operand, and
93
  - no user-defined conversions are applied to the left operand to achieve
94
  a type match with the left-most parameter of a built-in candidate.
95
 
96
  For all other operators, no such restrictions apply.
97
 
98
- The set of candidate functions for overload resolution is the union of
99
- the member candidates, the non-member candidates, and the built-in
100
- candidates. The argument list contains all of the operands of the
101
- operator. The best function from the set of candidate functions is
102
- selected according to  [[over.match.viable]] and 
103
- [[over.match.best]].[^6]
 
 
104
 
105
  [*Example 2*:
106
 
107
  ``` cpp
108
  struct A {
@@ -115,17 +137,36 @@ void m() {
115
  }
116
  ```
117
 
118
  — *end example*]
119
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
120
  If a built-in candidate is selected by overload resolution, the operands
121
  of class type are converted to the types of the corresponding parameters
122
  of the selected operation function, except that the second standard
123
- conversion sequence of a user-defined conversion sequence (
124
- [[over.ics.user]]) is not applied. Then the operator is treated as the
125
- corresponding built-in operator and interpreted according to Clause 
126
- [[expr]].
127
 
128
  [*Example 3*:
129
 
130
  ``` cpp
131
  struct X {
@@ -147,14 +188,14 @@ The second operand of operator `->` is ignored in selecting an
147
  function is called. When `operator->` returns, the operator `->` is
148
  applied to the value returned, with the original second operand.[^7]
149
 
150
  If the operator is the operator `,`, the unary operator `&`, or the
151
  operator `->`, and there are no viable functions, then the operator is
152
- assumed to be the built-in operator and interpreted according to Clause 
153
- [[expr]].
154
 
155
- [*Note 2*:
156
 
157
  The lookup rules for operators in expressions are different than the
158
  lookup rules for operator function names in a function call, as shown in
159
  the following example:
160
 
 
1
  #### Operators in expressions <a id="over.match.oper">[[over.match.oper]]</a>
2
 
3
  If no operand of an operator in an expression has a type that is a class
4
  or an enumeration, the operator is assumed to be a built-in operator and
5
+ interpreted according to [[expr.compound]].
6
 
7
  [*Note 1*: Because `.`, `.*`, and `::` cannot be overloaded, these
8
+ operators are always built-in operators interpreted according to
9
+ [[expr.compound]]. `?:` cannot be overloaded, but the rules in this
10
+ subclause are used to determine the conversions to be applied to the
11
+ second and third operands when they have class or enumeration type
12
+ [[expr.cond]]. — *end note*]
13
 
14
  [*Example 1*:
15
 
16
  ``` cpp
17
  struct String {
 
20
  operator const char* ();
21
  };
22
  String operator + (const String&, const String&);
23
 
24
  void f() {
25
+ const char* p= "one" + "two"; // error: cannot add two pointers; overloaded operator+ not considered
26
+ // because neither operand has class or enumeration type
27
  int I = 1 + 1; // always evaluates to 2 even if class or enumeration types exist
28
  // that would perform the operation.
29
  }
30
  ```
31
 
 
36
  operator or a user-defined conversion can be necessary to convert the
37
  operand to a type that is appropriate for a built-in operator. In this
38
  case, overload resolution is used to determine which operator function
39
  or built-in operator is to be invoked to implement the operator.
40
  Therefore, the operator notation is first transformed to the equivalent
41
+ function-call notation as summarized in [[over.match.oper]] (where `@`
42
+ denotes one of the operators covered in the specified subclause).
43
+ However, the operands are sequenced in the order prescribed for the
44
+ built-in operator [[expr.compound]].
45
 
46
+ **Table: Relationship between operator and function call notation** <a id="over.match.oper">[over.match.oper]</a>
47
 
48
  | Subclause | Expression | As member function | As non-member function |
49
  | ------------ | ---------- | ------------------- | ---------------------- |
50
  | (a)} |
51
  | (a, b)} |
 
53
  | [[over.sub]] | `a[b]` | `(a).operator[](b)` | |
54
  | [[over.ref]] | `a->` | `(a).operator->( )` | |
55
  | (a, 0)} |
56
 
57
 
58
+ For a unary operator `@` with an operand of type *cv1* `T1`, and for a
59
+ binary operator `@` with a left operand of type *cv1* `T1` and a right
60
+ operand of type *cv2* `T2`, four sets of candidate functions, designated
61
+ *member candidates*, *non-member candidates*, *built-in candidates*, and
62
+ *rewritten candidates*, are constructed as follows:
 
63
 
64
  - If `T1` is a complete class type or a class currently being defined,
65
  the set of member candidates is the result of the qualified lookup of
66
+ `T1::operator@` [[over.call.func]]; otherwise, the set of member
67
  candidates is empty.
68
  - The set of non-member candidates is the result of the unqualified
69
  lookup of `operator@` in the context of the expression according to
70
+ the usual rules for name lookup in unqualified function calls
71
+ [[basic.lookup.argdep]] except that all member functions are ignored.
72
  However, if no operand has a class type, only those non-member
73
  functions in the lookup set that have a first parameter of type `T1`
74
  or “reference to cv `T1`”, when `T1` is an enumeration type, or (if
75
  there is a right operand) a second parameter of type `T2` or
76
  “reference to cv `T2`”, when `T2` is an enumeration type, are
 
83
  - accept the same number of operands, and
84
  - accept operand types to which the given operand or operands can be
85
  converted according to [[over.best.ics]], and
86
  - do not have the same parameter-type-list as any non-member candidate
87
  that is not a function template specialization.
88
+ - The rewritten candidate set is determined as follows:
89
+ - For the relational [[expr.rel]] operators, the rewritten candidates
90
+ include all non-rewritten candidates for the expression `x <=> y`.
91
+ - For the relational [[expr.rel]] and three-way comparison
92
+ [[expr.spaceship]] operators, the rewritten candidates also include
93
+ a synthesized candidate, with the order of the two parameters
94
+ reversed, for each non-rewritten candidate for the expression
95
+ `y <=> x`.
96
+ - For the `!=` operator [[expr.eq]], the rewritten candidates include
97
+ all non-rewritten candidates for the expression `x == y`.
98
+ - For the equality operators, the rewritten candidates also include a
99
+ synthesized candidate, with the order of the two parameters
100
+ reversed, for each non-rewritten candidate for the expression
101
+ `y == x`.
102
+ - For all other operators, the rewritten candidate set is empty.
103
+
104
+ \[*Note 2*: A candidate synthesized from a member candidate has its
105
+ implicit object parameter as the second parameter, thus implicit
106
+ conversions are considered for the first, but not for the second,
107
+ parameter. — *end note*]
108
 
109
  For the built-in assignment operators, conversions of the left operand
110
  are restricted as follows:
111
 
112
  - no temporaries are introduced to hold the left operand, and
113
  - no user-defined conversions are applied to the left operand to achieve
114
  a type match with the left-most parameter of a built-in candidate.
115
 
116
  For all other operators, no such restrictions apply.
117
 
118
+ The set of candidate functions for overload resolution for some operator
119
+ `@` is the union of the member candidates, the non-member candidates,
120
+ the built-in candidates, and the rewritten candidates for that operator
121
+ `@`.
122
+
123
+ The argument list contains all of the operands of the operator. The best
124
+ function from the set of candidate functions is selected according to 
125
+ [[over.match.viable]] and  [[over.match.best]].[^6]
126
 
127
  [*Example 2*:
128
 
129
  ``` cpp
130
  struct A {
 
137
  }
138
  ```
139
 
140
  — *end example*]
141
 
142
+ If a rewritten `operator<=>` candidate is selected by overload
143
+ resolution for an operator `@`, `x @ y` is interpreted as
144
+ `0 @ (y <=> x)` if the selected candidate is a synthesized candidate
145
+ with reversed order of parameters, or `(x <=> y) @ 0` otherwise, using
146
+ the selected rewritten `operator<=>` candidate. Rewritten candidates for
147
+ the operator `@` are not considered in the context of the resulting
148
+ expression.
149
+
150
+ If a rewritten `operator==` candidate is selected by overload resolution
151
+ for an operator `@`, its return type shall be cv `bool`, and `x @ y` is
152
+ interpreted as:
153
+
154
+ - if `@` is `!=` and the selected candidate is a synthesized candidate
155
+ with reversed order of parameters, `!(y == x)`,
156
+ - otherwise, if `@` is `!=`, `!(x == y)`,
157
+ - otherwise (when `@` is `==`), `y == x`,
158
+
159
+ in each case using the selected rewritten `operator==` candidate.
160
+
161
  If a built-in candidate is selected by overload resolution, the operands
162
  of class type are converted to the types of the corresponding parameters
163
  of the selected operation function, except that the second standard
164
+ conversion sequence of a user-defined conversion sequence
165
+ [[over.ics.user]] is not applied. Then the operator is treated as the
166
+ corresponding built-in operator and interpreted according to
167
+ [[expr.compound]].
168
 
169
  [*Example 3*:
170
 
171
  ``` cpp
172
  struct X {
 
188
  function is called. When `operator->` returns, the operator `->` is
189
  applied to the value returned, with the original second operand.[^7]
190
 
191
  If the operator is the operator `,`, the unary operator `&`, or the
192
  operator `->`, and there are no viable functions, then the operator is
193
+ assumed to be the built-in operator and interpreted according to
194
+ [[expr.compound]].
195
 
196
+ [*Note 3*:
197
 
198
  The lookup rules for operators in expressions are different than the
199
  lookup rules for operator function names in a function call, as shown in
200
  the following example:
201