From Jason Turner

[constraints]

C++23 → Trunk 11.9 KB 190 lines
Current Draft | LaTeX Source
Archived: C++23
Markdown: C++23 | Trunk
Explore in Adventure Game
C++ Weekly: Ep 128 | Ep 196 | Ep 470

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpqg6r39gr/{from.md → to.md} +49 -131
tmp/tmpqg6r39gr/{from.md → to.md} RENAMED
@@ -19,13 +19,16 @@ Unless otherwise specified, the behavior of a C++ program is undefined
19
  if it adds declarations or definitions to namespace `std` or to a
20
  namespace within namespace `std`.
21
 
22
  Unless explicitly prohibited, a program may add a template
23
  specialization for any standard library class template to namespace
24
- `std` provided that (a) the added declaration depends on at least one
25
- program-defined type and (b) the specialization meets the standard
26
- library requirements for the original template.[^21]
 
 
 
27
 
28
  The behavior of a C++ program is undefined if it declares an explicit or
29
  partial specialization of any standard library variable template, except
30
  where explicitly permitted by the specification of that variable
31
  template.
@@ -43,13 +46,15 @@ The behavior of a C++ program is undefined if it declares
43
  - an explicit or partial specialization of any member class template of
44
  a standard library class or class template, or
45
  - a deduction guide for any standard library class template.
46
 
47
  A program may explicitly instantiate a class template defined in the
48
- standard library only if the declaration (a) depends on the name of at
49
- least one program-defined type and (b) the instantiation meets the
50
- standard library requirements for the original template.
 
 
51
 
52
  Let `F` denote a standard library function [[global.functions]], a
53
  standard library static member function, or an instantiation of a
54
  standard library function template. Unless `F` is designated an
55
  *addressable function*, the behavior of a C++ program is unspecified
@@ -65,19 +70,33 @@ Moreover, the behavior of a C++ program is unspecified (possibly
65
  ill-formed) if it attempts to form a reference to `F` or if it attempts
66
  to form a pointer-to-member designating either a standard library
67
  non-static member function [[member.functions]] or an instantiation of a
68
  standard library member function template.
69
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
70
  A translation unit shall not declare namespace `std` to be an inline
71
  namespace [[namespace.def]].
72
 
73
  ##### Namespace `posix` <a id="namespace.posix">[[namespace.posix]]</a>
74
 
75
  The behavior of a C++ program is undefined if it adds declarations or
76
  definitions to namespace `posix` or to a namespace within namespace
77
  `posix` unless otherwise specified. The namespace `posix` is reserved
78
- for use by ISO/IEC/IEEE 9945 and other POSIX standards.
79
 
80
  ##### Namespaces for future standardization <a id="namespace.future">[[namespace.future]]</a>
81
 
82
  Top-level namespaces whose *namespace-name* consists of `std` followed
83
  by one or more *digit*s [[lex.name]] are reserved for future
@@ -101,89 +120,29 @@ If a program declares or defines a name in a context where it is
101
  reserved, other than as explicitly allowed by [[library]], its behavior
102
  is undefined.
103
 
104
  ##### Zombie names <a id="zombie.names">[[zombie.names]]</a>
105
 
106
- In namespace `std`, the following names are reserved for previous
107
- standardization:
108
 
109
- - `auto_ptr`,
110
- - `auto_ptr_ref`,
111
- - `binary_function`,
112
- - `binary_negate`,
113
- - `bind1st`,
114
- - `bind2nd`,
115
- - `binder1st`,
116
- - `binder2nd`,
117
- - `const_mem_fun1_ref_t`,
118
- - `const_mem_fun1_t`,
119
- - `const_mem_fun_ref_t`,
120
- - `const_mem_fun_t`,
121
- - `declare_no_pointers`,
122
- - `declare_reachable`,
123
- - `get_pointer_safety`,
124
- - `get_temporary_buffer`,
125
- - `get_unexpected`,
126
- - `gets`,
127
- - `is_literal_type`,
128
- - `is_literal_type_v`,
129
- - `mem_fun1_ref_t`,
130
- - `mem_fun1_t`,
131
- - `mem_fun_ref_t`,
132
- - `mem_fun_ref`,
133
- - `mem_fun_t`,
134
- - `mem_fun`,
135
- - `not1`,
136
- - `not2`,
137
- - `pointer_safety`,
138
- - `pointer_to_binary_function`,
139
- - `pointer_to_unary_function`,
140
- - `ptr_fun`,
141
- - `random_shuffle`,
142
- - `raw_storage_iterator`,
143
- - `result_of`,
144
- - `result_of_t`,
145
- - `return_temporary_buffer`,
146
- - `set_unexpected`,
147
- - `unary_function`,
148
- - `unary_negate`,
149
- - `uncaught_exception`,
150
- - `undeclare_no_pointers`,
151
- - `undeclare_reachable`, and
152
- - `unexpected_handler`.
153
 
154
- The following names are reserved as members for previous
155
- standardization, and may not be used as a name for object-like macros in
156
- portable code:
157
 
158
- - `argument_type`,
159
- - `first_argument_type`,
160
- - `io_state`,
161
- - `open_mode`,
162
- - `preferred`,
163
- - `second_argument_type`,
164
- - `seek_dir`, and.
165
- - `strict`.
166
-
167
- The name `stossc` is reserved as a member function for previous
168
- standardization, and may not be used as a name for function-like macros
169
- in portable code.
170
-
171
- The header names `<ccomplex>`, `<ciso646>`, `<cstdalign>`, `<cstdbool>`,
172
- and `<ctgmath>` are reserved for previous standardization.
173
 
174
  ##### Macro names <a id="macro.names">[[macro.names]]</a>
175
 
176
  A translation unit that includes a standard library header shall not
177
  `#define` or `#undef` names declared in any standard library header.
178
 
179
- A translation unit shall not `#define` or `#undef` names lexically
180
- identical to keywords, to the identifiers listed in
181
- [[lex.name.special]], or to the *attribute-token*s described in 
182
- [[dcl.attr]], except that the names `likely` and `unlikely` may be
183
- defined as function-like macros  [[cpp.replace]].
184
-
185
  ##### External linkage <a id="extern.names">[[extern.names]]</a>
186
 
187
  Each name declared as an object with external linkage in a header is
188
  reserved to the implementation to designate that library object with
189
  external linkage, [^22]
@@ -231,56 +190,15 @@ Virtual member function signatures defined for a base class in the C++
231
  standard library may be overridden in a derived class defined in the
232
  program [[class.virtual]].
233
 
234
  #### Replacement functions <a id="replacement.functions">[[replacement.functions]]</a>
235
 
236
- [[support]] through [[thread]] and [[depr]] describe the behavior of
237
- numerous functions defined by the C++ standard library. Under some
238
- circumstances, however, certain of these function descriptions also
239
- apply to replacement functions defined in the program.
240
-
241
- A C++ program may provide the definition for any of the following
242
- dynamic memory allocation function signatures declared in header `<new>`
243
- [[basic.stc.dynamic]], [[new.syn]]:
244
-
245
- ``` cpp
246
- operator new(std::size_t)
247
- operator new(std::size_t, std::align_val_t)
248
- operator new(std::size_t, const std::nothrow_t&)
249
- operator new(std::size_t, std::align_val_t, const std::nothrow_t&)
250
- ```
251
-
252
- ``` cpp
253
- operator delete(void*)
254
- operator delete(void*, std::size_t)
255
- operator delete(void*, std::align_val_t)
256
- operator delete(void*, std::size_t, std::align_val_t)
257
- operator delete(void*, const std::nothrow_t&)
258
- operator delete(void*, std::align_val_t, const std::nothrow_t&)
259
- ```
260
-
261
- ``` cpp
262
- operator new[](std::size_t)
263
- operator new[](std::size_t, std::align_val_t)
264
- operator new[](std::size_t, const std::nothrow_t&)
265
- operator new[](std::size_t, std::align_val_t, const std::nothrow_t&)
266
- ```
267
-
268
- ``` cpp
269
- operator delete[](void*)
270
- operator delete[](void*, std::size_t)
271
- operator delete[](void*, std::align_val_t)
272
- operator delete[](void*, std::size_t, std::align_val_t)
273
- operator delete[](void*, const std::nothrow_t&)
274
- operator delete[](void*, std::align_val_t, const std::nothrow_t&)
275
- ```
276
-
277
- The program’s definitions are used instead of the default versions
278
- supplied by the implementation [[new.delete]]. Such replacement occurs
279
- prior to program startup [[basic.def.odr]], [[basic.start]]. The
280
- program’s declarations shall not be specified as `inline`. No diagnostic
281
- is required.
282
 
283
  #### Handler functions <a id="handler.functions">[[handler.functions]]</a>
284
 
285
  The C++ standard library provides a default version of the following
286
  handler function [[support]]:
@@ -301,14 +219,14 @@ A C++ program can get a pointer to the current handler function by
301
  calling the following functions:
302
 
303
  - `get_new_handler`
304
  - `get_terminate`
305
 
306
- Calling the `set_*` and `get_*` functions shall not incur a data race. A
307
- call to any of the `set_*` functions shall synchronize with subsequent
308
- calls to the same `set_*` function and to the corresponding `get_*`
309
- function.
310
 
311
  #### Other functions <a id="res.on.functions">[[res.on.functions]]</a>
312
 
313
  In certain cases (replacement functions, handler functions, operations
314
  on types used to instantiate standard library template components), the
@@ -316,13 +234,13 @@ C++ standard library depends on components supplied by a C++ program. If
316
  these components do not meet their requirements, this document places no
317
  requirements on the implementation.
318
 
319
  In particular, the behavior is undefined in the following cases:
320
 
321
- - For replacement functions [[new.delete]], if the installed replacement
322
- function does not implement the semantics of the applicable *Required
323
- behavior:* paragraph.
324
  - For handler functions [[new.handler]], [[terminate.handler]], if the
325
  installed handler function does not implement the semantics of the
326
  applicable *Required behavior:* paragraph.
327
  - For types used as template arguments when instantiating a template
328
  component, if the operations on the type do not implement the
@@ -350,11 +268,11 @@ the C++ standard library, unless explicitly stated otherwise.
350
  address computations and accesses to objects (that would be valid if
351
  the pointer did point to the first element of such an array) are in
352
  fact valid.
353
  - If a function argument is bound to an rvalue reference parameter, the
354
  implementation may assume that this parameter is a unique reference to
355
- this argument, except that the argument passed to a move-assignment
356
  operator may be a reference to `*this` [[lib.types.movedfrom]].
357
  \[*Note 1*: If the type of a parameter is a forwarding reference
358
  [[temp.deduct.call]] that is deduced to an lvalue reference type, then
359
  the argument is not bound to an rvalue reference. — *end note*]
360
  \[*Note 2*: If a program casts an lvalue to an xvalue while passing
 
19
  if it adds declarations or definitions to namespace `std` or to a
20
  namespace within namespace `std`.
21
 
22
  Unless explicitly prohibited, a program may add a template
23
  specialization for any standard library class template to namespace
24
+ `std` provided that
25
+
26
+ - the added declaration depends on at least one program-defined type,
27
+ and
28
+ - the specialization meets the standard library requirements for the
29
+ original template.[^21]
30
 
31
  The behavior of a C++ program is undefined if it declares an explicit or
32
  partial specialization of any standard library variable template, except
33
  where explicitly permitted by the specification of that variable
34
  template.
 
46
  - an explicit or partial specialization of any member class template of
47
  a standard library class or class template, or
48
  - a deduction guide for any standard library class template.
49
 
50
  A program may explicitly instantiate a class template defined in the
51
+ standard library only if the declaration
52
+
53
+ - depends on the name of at least one program-defined type, and
54
+ - the instantiation meets the standard library requirements for the
55
+ original template.
56
 
57
  Let `F` denote a standard library function [[global.functions]], a
58
  standard library static member function, or an instantiation of a
59
  standard library function template. Unless `F` is designated an
60
  *addressable function*, the behavior of a C++ program is unspecified
 
70
  ill-formed) if it attempts to form a reference to `F` or if it attempts
71
  to form a pointer-to-member designating either a standard library
72
  non-static member function [[member.functions]] or an instantiation of a
73
  standard library member function template.
74
 
75
+ Let `F` denote a standard library function or function template. Unless
76
+ `F` is designated an addressable function, it is unspecified if or how a
77
+ reflection value designating the associated entity can be formed.
78
+
79
+ [*Note 3*: For example, it is possible that `std::meta::members_of`
80
+ will not return reflections of standard library functions that an
81
+ implementation handles through an extra-linguistic
82
+ mechanism. — *end note*]
83
+
84
+ Let `C` denote a standard library class or class template
85
+ specialization. It is unspecified if or how a reflection value can be
86
+ formed to any private member of `C`, or what the names of such members
87
+ may be.
88
+
89
  A translation unit shall not declare namespace `std` to be an inline
90
  namespace [[namespace.def]].
91
 
92
  ##### Namespace `posix` <a id="namespace.posix">[[namespace.posix]]</a>
93
 
94
  The behavior of a C++ program is undefined if it adds declarations or
95
  definitions to namespace `posix` or to a namespace within namespace
96
  `posix` unless otherwise specified. The namespace `posix` is reserved
97
+ for use by \IsoPosixUndated and other POSIX standards.
98
 
99
  ##### Namespaces for future standardization <a id="namespace.future">[[namespace.future]]</a>
100
 
101
  Top-level namespaces whose *namespace-name* consists of `std` followed
102
  by one or more *digit*s [[lex.name]] are reserved for future
 
120
  reserved, other than as explicitly allowed by [[library]], its behavior
121
  is undefined.
122
 
123
  ##### Zombie names <a id="zombie.names">[[zombie.names]]</a>
124
 
125
+ In namespace `std`, the names shown in [[zombie.names.std]] are reserved
126
+ for previous standardization:
127
 
128
+ The names shown in [[zombie.names.objmacro]] are reserved as members for
129
+ previous standardization, and may not be used as a name for object-like
130
+ macros in portable code:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
131
 
132
+ The names shown in [[zombie.names.fnmacro]] are reserved as member
133
+ functions for previous standardization, and may not be used as a name
134
+ for function-like macros in portable code:
135
 
136
+ The header names shown in [[zombie.names.header]] are reserved for
137
+ previous standardization:
 
 
 
 
 
 
 
 
 
 
 
 
 
138
 
139
  ##### Macro names <a id="macro.names">[[macro.names]]</a>
140
 
141
  A translation unit that includes a standard library header shall not
142
  `#define` or `#undef` names declared in any standard library header.
143
 
 
 
 
 
 
 
144
  ##### External linkage <a id="extern.names">[[extern.names]]</a>
145
 
146
  Each name declared as an object with external linkage in a header is
147
  reserved to the implementation to designate that library object with
148
  external linkage, [^22]
 
190
  standard library may be overridden in a derived class defined in the
191
  program [[class.virtual]].
192
 
193
  #### Replacement functions <a id="replacement.functions">[[replacement.functions]]</a>
194
 
195
+ If a function defined in [[support]] through [[exec]] and [[depr]] is
196
+ specified as replaceable [[term.replaceable.function]], the description
197
+ of function semantics apply to both the default version defined by the
198
+ C++ standard library and the replacement function defined by the
199
+ program.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
200
 
201
  #### Handler functions <a id="handler.functions">[[handler.functions]]</a>
202
 
203
  The C++ standard library provides a default version of the following
204
  handler function [[support]]:
 
219
  calling the following functions:
220
 
221
  - `get_new_handler`
222
  - `get_terminate`
223
 
224
+ Calling the `set_*` and `get_*` functions shall not incur a data race
225
+ [[intro.races]]. A call to any of the `set_*` functions synchronizes
226
+ with subsequent calls to the same `set_*` function and to the
227
+ corresponding `get_*` function.
228
 
229
  #### Other functions <a id="res.on.functions">[[res.on.functions]]</a>
230
 
231
  In certain cases (replacement functions, handler functions, operations
232
  on types used to instantiate standard library template components), the
 
234
  these components do not meet their requirements, this document places no
235
  requirements on the implementation.
236
 
237
  In particular, the behavior is undefined in the following cases:
238
 
239
+ - For replacement functions [[replacement.functions]], if the installed
240
+ replacement function does not implement the semantics of the
241
+ applicable *Required behavior:* paragraph.
242
  - For handler functions [[new.handler]], [[terminate.handler]], if the
243
  installed handler function does not implement the semantics of the
244
  applicable *Required behavior:* paragraph.
245
  - For types used as template arguments when instantiating a template
246
  component, if the operations on the type do not implement the
 
268
  address computations and accesses to objects (that would be valid if
269
  the pointer did point to the first element of such an array) are in
270
  fact valid.
271
  - If a function argument is bound to an rvalue reference parameter, the
272
  implementation may assume that this parameter is a unique reference to
273
+ this argument, except that the argument passed to a move assignment
274
  operator may be a reference to `*this` [[lib.types.movedfrom]].
275
  \[*Note 1*: If the type of a parameter is a forwarding reference
276
  [[temp.deduct.call]] that is deduced to an lvalue reference type, then
277
  the argument is not bound to an rvalue reference. — *end note*]
278
  \[*Note 2*: If a program casts an lvalue to an xvalue while passing