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

Files changed (1) hide show

tmp/tmpuipvr1y7/{from.md → to.md} +157 -77

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

@@ -1,29 +1,36 @@
 ### Constraints on programs <a id="constraints">[[constraints]]</a>
 #### Overview <a id="constraints.overview">[[constraints.overview]]</a>
-This section describes restrictions on C++programs that use the
-facilities of the C++standard library. The following subclauses specify
-constraints on the program’s use of namespaces ([[namespace.std]]), its
-use of various reserved names ([[reserved.names]]), its use of
-headers ([[alt.headers]]), its use of standard library classes as base
-classes ([[derived.classes]]), its definitions of replacement
-functions ([[replacement.functions]]), and its installation of handler
-functions during execution ([[handler.functions]]).
 #### Namespace use <a id="namespace.constraints">[[namespace.constraints]]</a>
 ##### Namespace `std` <a id="namespace.std">[[namespace.std]]</a>
-The behavior of a C++program is undefined if it adds declarations or
-definitions to namespace `std` or to a namespace within namespace `std`
-unless otherwise specified. A program may add a template specialization
-for any standard library template to namespace `std` only if the
-declaration depends on a user-defined type and the specialization meets
-the standard library requirements for the original template and is not
-explicitly prohibited.[^21]
 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
@@ -31,33 +38,62 @@ The behavior of a C++program is undefined if it declares
   standard library class or class template, or
 - an explicit or partial specialization of any member class template of
   a standard library class or class template, or
 - a deduction guide for any standard library class template.
-A program may explicitly instantiate a template defined in the standard
-library only if the declaration depends on the name of a user-defined
-type and the instantiation meets the standard library requirements for
-the original 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 9945 and other POSIX standards.
 ##### Namespaces for future standardization <a id="namespace.future">[[namespace.future]]</a>
-Top level namespaces with a name starting with `std` and followed by a
-non-empty sequence of digits are reserved for future standardization.
-The behavior of a C++program is undefined if it adds 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:
@@ -74,101 +110,133 @@ is undefined.
 In namespace `std`, the following names are reserved for previous
 standardization:
 - `auto_ptr`,
 - `binary_function`,
 - `bind1st`,
 - `bind2nd`,
 - `binder1st`,
 - `binder2nd`,
 - `const_mem_fun1_ref_t`,
 - `const_mem_fun1_t`,
 - `const_mem_fun_ref_t`,
 - `const_mem_fun_t`,
 - `get_unexpected`,
 - `mem_fun1_ref_t`,
 - `mem_fun1_t`,
 - `mem_fun_ref_t`,
 - `mem_fun_ref`,
 - `mem_fun_t`,
 - `mem_fun`,
 - `pointer_to_binary_function`,
 - `pointer_to_unary_function`,
 - `ptr_fun`,
 - `random_shuffle`,
 - `set_unexpected`,
 - `unary_function`,
 - `unexpected`, and
 - `unexpected_handler`.
 ##### Macro names <a id="macro.names">[[macro.names]]</a>
 A translation unit that includes a standard library header shall not
 `#define` or `#undef` names declared in any standard library header.
 A translation unit shall not `#define` or `#undef` names lexically
-identical to keywords, to the identifiers listed in Table
-[[tab:identifiers.special]], or to the *attribute-token*s described in
-[[dcl.attr]].
 ##### 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,[^25] 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
 implementation, and a file with that name is placed in any of the
-standard places for a source file to be included ([[cpp.include]]), the
 behavior is undefined.
 #### Derived classes <a id="derived.classes">[[derived.classes]]</a>
-Virtual member function signatures defined for a base class in the
-C++standard library may be overridden in a derived class defined in the
-program ([[class.virtual]]).
 #### Replacement functions <a id="replacement.functions">[[replacement.functions]]</a>
-Clauses  [[language.support]] through  [[thread]] and Annex  [[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]], [[support.dynamic]]):
 ``` cpp
 operator new(std::size_t)
 operator new(std::size_t, std::align_val_t)
 operator new(std::size_t, const std::nothrow_t&)
@@ -199,19 +267,19 @@ operator delete[](void*, std::size_t, std::align_val_t)
 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 ([[support.dynamic]]). 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>
 The C++ standard library provides a default version of the following
-handler function (Clause  [[language.support]]):
 - `terminate_handler`
 A C++ program may install different handler functions during execution,
 by supplying a pointer to a function defined in the program or the
@@ -237,34 +305,34 @@ function.
 #### Other functions <a id="res.on.functions">[[res.on.functions]]</a>
 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 International
-Standard 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, 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.
@@ -279,41 +347,53 @@ the C++standard library, unless explicitly stated otherwise.
   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. 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
 conditions under which this may occur are specified in
 [[res.on.data.races]].
 [*Note 1*: Modifying an object of a standard library type that is
 shared between threads risks undefined behavior unless objects of that
-type are explicitly specified as being sharable without data races or
 the user supplies a locking mechanism. — *end note*]
 If an object of a standard library type is accessed, and the beginning
-of the object’s lifetime ([[basic.life]]) does not happen before the
 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*]
-#### Requires paragraph <a id="res.on.required">[[res.on.required]]</a>
-Violation of the preconditions specified in a function’s *Requires:*
-paragraph results in undefined behavior unless the function’s *Throws:*
-paragraph specifies throwing an exception when the precondition is
-violated.

 ### Constraints on programs <a id="constraints">[[constraints]]</a>
 #### Overview <a id="constraints.overview">[[constraints.overview]]</a>
+Subclause [[constraints]] describes restrictions on C++ programs that
+use the facilities of the C++ standard library. The following subclauses
+specify constraints on the program’s use of namespaces
+[[namespace.std]], its use of various reserved names [[reserved.names]],
+its use of headers [[alt.headers]], its use of standard library classes
+as base classes [[derived.classes]], its definitions of replacement
+functions [[replacement.functions]], and its installation of handler
+functions during execution [[handler.functions]].
 #### Namespace use <a id="namespace.constraints">[[namespace.constraints]]</a>
 ##### Namespace `std` <a id="namespace.std">[[namespace.std]]</a>
+Unless otherwise specified, the behavior of a C++ program is undefined
+if it adds declarations or definitions to namespace `std` or to a
+namespace within namespace `std`.
+Unless explicitly prohibited, a program may add a template
+specialization for any standard library class template to namespace
+`std` provided that (a) the added declaration depends on at least one
+program-defined type and (b) the specialization meets the standard
+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
   standard library class or class template, or
 - an explicit or partial specialization of any member class template of
   a standard library class or class template, or
 - a deduction guide for any standard library class template.
+A program may explicitly instantiate a class template defined in the
+standard library only if the declaration (a) depends on the name of at
+least one program-defined type and (b) the instantiation meets the
+standard library requirements for the original template.
+Let `F` denote a standard library function [[global.functions]], a
+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
+standardization. The behavior of a C++ program is undefined if it adds
+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:
 In namespace `std`, the following names are reserved for previous
 standardization:
 - `auto_ptr`,
+- `auto_ptr_ref`,
 - `binary_function`,
+- `binary_negate`,
 - `bind1st`,
 - `bind2nd`,
 - `binder1st`,
 - `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`,
 - `mem_fun1_ref_t`,
 - `mem_fun1_t`,
 - `mem_fun_ref_t`,
 - `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`,
+- `result_of`,
+- `result_of_t`,
+- `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.
+The header names `<ccomplex>`, `<ciso646>`, `<cstdalign>`, `<cstdbool>`,
+and `<ctgmath>` are reserved for previous standardization.
 ##### Macro names <a id="macro.names">[[macro.names]]</a>
 A translation unit that includes a standard library header shall not
 `#define` or `#undef` names declared in any standard library header.
 A translation unit shall not `#define` or `#undef` names lexically
+identical to keywords, to the identifiers listed in
+[[lex.name.special]], or to the *attribute-token*s described in
+[[dcl.attr]], except that the names `likely` and `unlikely` may be
+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
 implementation, and a file with that name is placed in any of the
+standard places for a source file to be included [[cpp.include]], the
 behavior is undefined.
 #### Derived classes <a id="derived.classes">[[derived.classes]]</a>
+Virtual member function signatures defined for a base class in the C++
+standard library may be overridden in a derived class defined in the
+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&)
 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>
 The C++ standard library provides a default version of the following
+handler function [[support]]:
 - `terminate_handler`
 A C++ program may install different handler functions during execution,
 by supplying a pointer to a function defined in the program or the
 #### Other functions <a id="res.on.functions">[[res.on.functions]]</a>
 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.
   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
 conditions under which this may occur are specified in
 [[res.on.data.races]].
 [*Note 1*: Modifying an object of a standard library type that is
 shared between threads risks undefined behavior unless objects of that
+type are explicitly specified as being shareable without data races or
 the user supplies a locking mechanism. — *end note*]
 If an object of a standard library type is accessed, and the beginning
+of the object’s lifetime [[basic.life]] does not happen before the
 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`.
+If the validity or meaning of a program depends on whether a sequence of
+template arguments models a concept, and the concept is satisfied but
+not modeled, the program is ill-formed, no diagnostic required.
+If the semantic requirements of a declaration’s constraints
+[[structure.requirements]] are not modeled at the point of use, the
+program is ill-formed, no diagnostic required.

Diff to HTML by rtfpessoa