[constraints] - C++20 → C++23

Files changed (1) hide show

tmp/tmpf6wpcsbw/{from.md → to.md} +56 -55

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

@@ -28,10 +28,14 @@ library requirements for the original template.[^21]
 The behavior of a C++ program is undefined if it declares an explicit or
 partial specialization of any standard library variable template, except
 where explicitly permitted by the specification of that variable
 template.
 The behavior of a C++ program is undefined if it declares
 - an explicit specialization of any member function of a standard
   library class template, or
 - an explicit specialization of any member function template of a
@@ -50,41 +54,30 @@ standard library static member function, or an instantiation of a
 standard library function template. Unless `F` is designated an
 *addressable function*, the behavior of a C++ program is unspecified
 (possibly ill-formed) if it explicitly or implicitly attempts to form a
 pointer to `F`.
-[*Note 1*: Possible means of forming such pointers include application
 of the unary `&` operator [[expr.unary.op]], `addressof`
 [[specialized.addressof]], or a function-to-pointer standard conversion
 [[conv.func]]. — *end note*]
 Moreover, the behavior of a C++ program is unspecified (possibly
 ill-formed) if it attempts to form a reference to `F` or if it attempts
 to form a pointer-to-member designating either a standard library
 non-static member function [[member.functions]] or an instantiation of a
 standard library member function template.
-Other than in namespace `std` or in a namespace within namespace `std`,
-a program may provide an overload for any library function template
-designated as a *customization point*, provided that (a) the overload’s
-declaration depends on at least one user-defined type and (b) the
-overload meets the standard library requirements for the customization
-point. [^22]
-[*Note 2*: This permits a (qualified or unqualified) call to the
-customization point to invoke the most appropriate overload for the
-given arguments. — *end note*]
 A translation unit shall not declare namespace `std` to be an inline
 namespace [[namespace.def]].
 ##### Namespace `posix` <a id="namespace.posix">[[namespace.posix]]</a>
 The behavior of a C++ program is undefined if it adds declarations or
 definitions to namespace `posix` or to a namespace within namespace
 `posix` unless otherwise specified. The namespace `posix` is reserved
-for use by ISO/IEC 9945 and other POSIX standards.
 ##### Namespaces for future standardization <a id="namespace.future">[[namespace.future]]</a>
 Top-level namespaces whose *namespace-name* consists of `std` followed
 by one or more *digit*s [[lex.name]] are reserved for future
@@ -94,18 +87,20 @@ declarations or definitions to such a namespace.
 [*Example 1*: The top-level namespace `std2` is reserved for use by
 future revisions of this International Standard. — *end example*]
 #### Reserved names <a id="reserved.names">[[reserved.names]]</a>
 The C++ standard library reserves the following kinds of names:
 - macros
 - global names
 - names with external linkage
 If a program declares or defines a name in a context where it is
-reserved, other than as explicitly allowed by this Clause, its behavior
 is undefined.
 ##### Zombie names <a id="zombie.names">[[zombie.names]]</a>
 In namespace `std`, the following names are reserved for previous
@@ -121,10 +116,13 @@ standardization:
 - `binder2nd`,
 - `const_mem_fun1_ref_t`,
 - `const_mem_fun1_t`,
 - `const_mem_fun_ref_t`,
 - `const_mem_fun_t`,
 - `get_temporary_buffer`,
 - `get_unexpected`,
 - `gets`,
 - `is_literal_type`,
 - `is_literal_type_v`,
@@ -134,10 +132,11 @@ standardization:
 - `mem_fun_ref`,
 - `mem_fun_t`,
 - `mem_fun`,
 - `not1`,
 - `not2`,
 - `pointer_to_binary_function`,
 - `pointer_to_unary_function`,
 - `ptr_fun`,
 - `random_shuffle`,
 - `raw_storage_iterator`,
@@ -146,23 +145,26 @@ standardization:
 - `return_temporary_buffer`,
 - `set_unexpected`,
 - `unary_function`,
 - `unary_negate`,
 - `uncaught_exception`,
-- `unexpected`, and
 - `unexpected_handler`.
-The following names are reserved as member types for previous
 standardization, and may not be used as a name for object-like macros in
 portable code:
 - `argument_type`,
 - `first_argument_type`,
 - `io_state`,
 - `open_mode`,
-- `second_argument_type`, and
-- `seek_dir`.
 The name `stossc` is reserved as a member function for previous
 standardization, and may not be used as a name for function-like macros
 in portable code.
@@ -182,36 +184,40 @@ defined as function-like macros  [[cpp.replace]].
 ##### External linkage <a id="extern.names">[[extern.names]]</a>
 Each name declared as an object with external linkage in a header is
 reserved to the implementation to designate that library object with
-external linkage, [^23] both in namespace `std` and in the global
-namespace.
 Each global function signature declared with external linkage in a
 header is reserved to the implementation to designate that function
-signature with external linkage.[^24]
 Each name from the C standard library declared with external linkage is
 reserved to the implementation for use as a name with `extern "C"`
 linkage, both in namespace `std` and in the global namespace.
 Each function signature from the C standard library declared with
 external linkage is reserved to the implementation for use as a function
-signature with both `extern "C"` and `extern "C++"` linkage,[^25] or as
-a name of namespace scope in the global namespace.
 ##### Types <a id="extern.types">[[extern.types]]</a>
 For each type `T` from the C standard library, the types `::T` and
 `std::T` are reserved to the implementation and, when defined, `::T`
 shall be identical to `std::T`.
 ##### User-defined literal suffixes <a id="usrlit.suffix">[[usrlit.suffix]]</a>
 Literal suffix identifiers [[over.literal]] that do not start with an
-underscore are reserved for future standardization.
 #### Headers <a id="alt.headers">[[alt.headers]]</a>
 If a file with a name equivalent to the derived file name for one of the
 C++ standard library headers is not provided as part of the
@@ -228,15 +234,15 @@ program [[class.virtual]].
 #### Replacement functions <a id="replacement.functions">[[replacement.functions]]</a>
 [[support]] through [[thread]] and [[depr]] describe the behavior of
 numerous functions defined by the C++ standard library. Under some
 circumstances, however, certain of these function descriptions also
-apply to replacement functions defined in the program [[definitions]].
 A C++ program may provide the definition for any of the following
-dynamic memory allocation function signatures declared in header
-`<new>` ([[basic.stc.dynamic]], [[new.syn]]):
 ``` cpp
 operator new(std::size_t)
 operator new(std::size_t, std::align_val_t)
 operator new(std::size_t, const std::nothrow_t&)
@@ -268,11 +274,11 @@ operator delete[](void*, const std::nothrow_t&)
 operator delete[](void*, std::align_val_t, const std::nothrow_t&)
 ```
 The program’s definitions are used instead of the default versions
 supplied by the implementation [[new.delete]]. Such replacement occurs
-prior to program startup ([[basic.def.odr]], [[basic.start]]). The
 program’s declarations shall not be specified as `inline`. No diagnostic
 is required.
 #### Handler functions <a id="handler.functions">[[handler.functions]]</a>
@@ -308,31 +314,30 @@ In certain cases (replacement functions, handler functions, operations
 on types used to instantiate standard library template components), the
 C++ standard library depends on components supplied by a C++ program. If
 these components do not meet their requirements, this document places no
 requirements on the implementation.
-In particular, the effects are undefined in the following cases:
 - For replacement functions [[new.delete]], if the installed replacement
   function does not implement the semantics of the applicable *Required
   behavior:* paragraph.
-- For handler functions ([[new.handler]], [[terminate.handler]]), if
- the installed handler function does not implement the semantics of the
   applicable *Required behavior:* paragraph.
 - For types used as template arguments when instantiating a template
   component, if the operations on the type do not implement the
-  semantics of the applicable *Requirements* subclause (
-  [[allocator.requirements]], [[container.requirements]],
- [[iterator.requirements]], [[algorithms.requirements]],
- [[numeric.requirements]]). Operations on such types can report a
-  failure by throwing an exception unless otherwise specified.
 - If any replacement function or handler function or destructor
   operation exits via an exception, unless specifically allowed in the
   applicable *Required behavior:* paragraph.
-- If an incomplete type [[basic.types]] is used as a template argument
-  when instantiating a template component or evaluating a concept,
-  unless specifically allowed for that component.
 #### Function arguments <a id="res.on.arguments">[[res.on.arguments]]</a>
 Each of the following applies to all arguments to functions defined in
 the C++ standard library, unless explicitly stated otherwise.
@@ -343,22 +348,23 @@ the C++ standard library, unless explicitly stated otherwise.
 - If a function argument is described as being an array, the pointer
   actually passed to the function shall have a value such that all
   address computations and accesses to objects (that would be valid if
   the pointer did point to the first element of such an array) are in
   fact valid.
-- If a function argument binds to an rvalue reference parameter, the
   implementation may assume that this parameter is a unique reference to
-  this argument. \[*Note 1*: If the parameter is a generic parameter of
- the form `T&&` and an lvalue of type `A` is bound, the argument binds
- to an lvalue reference [[temp.deduct.call]] and thus is not covered by
- the previous sentence. — *end note*] \[*Note 2*: If a program casts
- an lvalue to an xvalue while passing that lvalue to a library function
- (e.g., by calling the function with the argument `std::move(x)`), the
- program is effectively asking that function to treat that lvalue as a
- temporary object. The implementation is free to optimize away aliasing
- checks which might be needed if the argument was an
- lvalue. — *end note*]
 #### Library object access <a id="res.on.objects">[[res.on.objects]]</a>
 The behavior of a program is undefined if calls to standard library
 functions from different threads may introduce a data race. The
@@ -376,15 +382,10 @@ access, or the access does not happen before the end of the object’s
 lifetime, the behavior is undefined unless otherwise specified.
 [*Note 2*: This applies even to objects such as mutexes intended for
 thread synchronization. — *end note*]
-#### Expects paragraph <a id="res.on.expects">[[res.on.expects]]</a>
-Violation of any preconditions specified in a function’s
-*Preconditions:* element results in undefined behavior.
 #### Semantic requirements <a id="res.on.requirements">[[res.on.requirements]]</a>
 A sequence `Args` of template arguments is said to *model* a concept `C`
 if `Args` satisfies `C` [[temp.constr.decl]] and meets all semantic
 requirements (if any) given in the specification of `C`.

 The behavior of a C++ program is undefined if it declares an explicit or
 partial specialization of any standard library variable template, except
 where explicitly permitted by the specification of that variable
 template.
+[*Note 1*: The requirements on an explicit or partial specialization
+are stated by each variable template that grants such
+permission. — *end note*]
 The behavior of a C++ program is undefined if it declares
 - an explicit specialization of any member function of a standard
   library class template, or
 - an explicit specialization of any member function template of a
 standard library function template. Unless `F` is designated an
 *addressable function*, the behavior of a C++ program is unspecified
 (possibly ill-formed) if it explicitly or implicitly attempts to form a
 pointer to `F`.
+[*Note 2*: Possible means of forming such pointers include application
 of the unary `&` operator [[expr.unary.op]], `addressof`
 [[specialized.addressof]], or a function-to-pointer standard conversion
 [[conv.func]]. — *end note*]
 Moreover, the behavior of a C++ program is unspecified (possibly
 ill-formed) if it attempts to form a reference to `F` or if it attempts
 to form a pointer-to-member designating either a standard library
 non-static member function [[member.functions]] or an instantiation of a
 standard library member function template.
 A translation unit shall not declare namespace `std` to be an inline
 namespace [[namespace.def]].
 ##### Namespace `posix` <a id="namespace.posix">[[namespace.posix]]</a>
 The behavior of a C++ program is undefined if it adds declarations or
 definitions to namespace `posix` or to a namespace within namespace
 `posix` unless otherwise specified. The namespace `posix` is reserved
+for use by ISO/IEC/IEEE 9945 and other POSIX standards.
 ##### Namespaces for future standardization <a id="namespace.future">[[namespace.future]]</a>
 Top-level namespaces whose *namespace-name* consists of `std` followed
 by one or more *digit*s [[lex.name]] are reserved for future
 [*Example 1*: The top-level namespace `std2` is reserved for use by
 future revisions of this International Standard. — *end example*]
 #### Reserved names <a id="reserved.names">[[reserved.names]]</a>
+##### General <a id="reserved.names.general">[[reserved.names.general]]</a>
 The C++ standard library reserves the following kinds of names:
 - macros
 - global names
 - names with external linkage
 If a program declares or defines a name in a context where it is
+reserved, other than as explicitly allowed by [[library]], its behavior
 is undefined.
 ##### Zombie names <a id="zombie.names">[[zombie.names]]</a>
 In namespace `std`, the following names are reserved for previous
 - `binder2nd`,
 - `const_mem_fun1_ref_t`,
 - `const_mem_fun1_t`,
 - `const_mem_fun_ref_t`,
 - `const_mem_fun_t`,
+- `declare_no_pointers`,
+- `declare_reachable`,
+- `get_pointer_safety`,
 - `get_temporary_buffer`,
 - `get_unexpected`,
 - `gets`,
 - `is_literal_type`,
 - `is_literal_type_v`,
 - `mem_fun_ref`,
 - `mem_fun_t`,
 - `mem_fun`,
 - `not1`,
 - `not2`,
+- `pointer_safety`,
 - `pointer_to_binary_function`,
 - `pointer_to_unary_function`,
 - `ptr_fun`,
 - `random_shuffle`,
 - `raw_storage_iterator`,
 - `return_temporary_buffer`,
 - `set_unexpected`,
 - `unary_function`,
 - `unary_negate`,
 - `uncaught_exception`,
+- `undeclare_no_pointers`,
+- `undeclare_reachable`, and
 - `unexpected_handler`.
+The following names are reserved as members for previous
 standardization, and may not be used as a name for object-like macros in
 portable code:
 - `argument_type`,
 - `first_argument_type`,
 - `io_state`,
 - `open_mode`,
+- `preferred`,
+- `second_argument_type`,
+- `seek_dir`, and.
+- `strict`.
 The name `stossc` is reserved as a member function for previous
 standardization, and may not be used as a name for function-like macros
 in portable code.
 ##### External linkage <a id="extern.names">[[extern.names]]</a>
 Each name declared as an object with external linkage in a header is
 reserved to the implementation to designate that library object with
+external linkage, [^22]
+both in namespace `std` and in the global namespace.
 Each global function signature declared with external linkage in a
 header is reserved to the implementation to designate that function
+signature with external linkage.[^23]
 Each name from the C standard library declared with external linkage is
 reserved to the implementation for use as a name with `extern "C"`
 linkage, both in namespace `std` and in the global namespace.
 Each function signature from the C standard library declared with
 external linkage is reserved to the implementation for use as a function
+signature with both `extern "C"` and `extern "C++"` linkage,[^24]
+or as a name of namespace scope in the global namespace.
 ##### Types <a id="extern.types">[[extern.types]]</a>
 For each type `T` from the C standard library, the types `::T` and
 `std::T` are reserved to the implementation and, when defined, `::T`
 shall be identical to `std::T`.
 ##### User-defined literal suffixes <a id="usrlit.suffix">[[usrlit.suffix]]</a>
 Literal suffix identifiers [[over.literal]] that do not start with an
+underscore are reserved for future standardization. Literal suffix
+identifiers that contain a double underscore `__` are reserved for use
+by C++ implementations.
 #### Headers <a id="alt.headers">[[alt.headers]]</a>
 If a file with a name equivalent to the derived file name for one of the
 C++ standard library headers is not provided as part of the
 #### Replacement functions <a id="replacement.functions">[[replacement.functions]]</a>
 [[support]] through [[thread]] and [[depr]] describe the behavior of
 numerous functions defined by the C++ standard library. Under some
 circumstances, however, certain of these function descriptions also
+apply to replacement functions defined in the program.
 A C++ program may provide the definition for any of the following
+dynamic memory allocation function signatures declared in header `<new>`
+[[basic.stc.dynamic]], [[new.syn]]:
 ``` cpp
 operator new(std::size_t)
 operator new(std::size_t, std::align_val_t)
 operator new(std::size_t, const std::nothrow_t&)
 operator delete[](void*, std::align_val_t, const std::nothrow_t&)
 ```
 The program’s definitions are used instead of the default versions
 supplied by the implementation [[new.delete]]. Such replacement occurs
+prior to program startup [[basic.def.odr]], [[basic.start]]. The
 program’s declarations shall not be specified as `inline`. No diagnostic
 is required.
 #### Handler functions <a id="handler.functions">[[handler.functions]]</a>
 on types used to instantiate standard library template components), the
 C++ standard library depends on components supplied by a C++ program. If
 these components do not meet their requirements, this document places no
 requirements on the implementation.
+In particular, the behavior is undefined in the following cases:
 - For replacement functions [[new.delete]], if the installed replacement
   function does not implement the semantics of the applicable *Required
   behavior:* paragraph.
+- For handler functions [[new.handler]], [[terminate.handler]], if the
+  installed handler function does not implement the semantics of the
   applicable *Required behavior:* paragraph.
 - For types used as template arguments when instantiating a template
   component, if the operations on the type do not implement the
+  semantics of the applicable *Requirements* subclause
+  [[allocator.requirements]], [[container.requirements]], [[iterator.requirements]], [[algorithms.requirements]], [[numeric.requirements]].
+ Operations on such types can report a failure by throwing an exception
+ unless otherwise specified.
 - If any replacement function or handler function or destructor
   operation exits via an exception, unless specifically allowed in the
   applicable *Required behavior:* paragraph.
+- If an incomplete type [[term.incomplete.type]] is used as a template
+ argument when instantiating a template component or evaluating a
+ concept, unless specifically allowed for that component.
 #### Function arguments <a id="res.on.arguments">[[res.on.arguments]]</a>
 Each of the following applies to all arguments to functions defined in
 the C++ standard library, unless explicitly stated otherwise.
 - If a function argument is described as being an array, the pointer
   actually passed to the function shall have a value such that all
   address computations and accesses to objects (that would be valid if
   the pointer did point to the first element of such an array) are in
   fact valid.
+- If a function argument is bound to an rvalue reference parameter, the
   implementation may assume that this parameter is a unique reference to
+  this argument, except that the argument passed to a move-assignment
+ operator may be a reference to `*this` [[lib.types.movedfrom]].
+ \[*Note 1*: If the type of a parameter is a forwarding reference
+ [[temp.deduct.call]] that is deduced to an lvalue reference type, then
+ the argument is not bound to an rvalue reference. — *end note*]
+ \[*Note 2*: If a program casts an lvalue to an xvalue while passing
+ that lvalue to a library function (e.g., by calling the function with
+ the argument `std::move(x)`), the program is effectively asking that
+ function to treat that lvalue as a temporary object. The
+ implementation is free to optimize away aliasing checks which would
+  possibly be needed if the argument was an lvalue. — *end note*]
 #### Library object access <a id="res.on.objects">[[res.on.objects]]</a>
 The behavior of a program is undefined if calls to standard library
 functions from different threads may introduce a data race. The
 lifetime, the behavior is undefined unless otherwise specified.
 [*Note 2*: This applies even to objects such as mutexes intended for
 thread synchronization. — *end note*]
 #### Semantic requirements <a id="res.on.requirements">[[res.on.requirements]]</a>
 A sequence `Args` of template arguments is said to *model* a concept `C`
 if `Args` satisfies `C` [[temp.constr.decl]] and meets all semantic
 requirements (if any) given in the specification of `C`.

Diff to HTML by rtfpessoa