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

Files changed (1) hide show

tmp/tmphiwwgh95/{from.md → to.md} +125 -73

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

@@ -19,20 +19,21 @@ 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.[^22]
 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 class or class template, or
 - an explicit or partial specialization of any member class template of
-  a standard library class or 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.
@@ -45,10 +46,20 @@ namespace ([[namespace.def]]).
 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.
 #### Reserved names <a id="reserved.names">[[reserved.names]]</a>
 The C++standard library reserves the following kinds of names:
 - macros
@@ -57,61 +68,81 @@ The C++standard library reserves the following kinds of names:
 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.
 ##### 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]].
-##### Global names <a id="global.names">[[global.names]]</a>
-Certain sets of names and function signatures are always reserved to the
-implementation:
-- Each name that contains a double underscore `__` or begins with an
-  underscore followed by an uppercase letter ([[lex.key]]) is reserved
-  to the implementation for any use.
-- Each name that begins with an underscore is reserved to the
-  implementation for use as a name in the global namespace.
 ##### 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 Standard C 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 Standard C 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 Standard C library,[^26] 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 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
@@ -131,55 +162,73 @@ 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 twelve dynamic memory
-allocation function signatures declared in header `<new>` (
 [[basic.stc.dynamic]], [[support.dynamic]]):
-- `operator new(std::size_t)`
-- `operator new(std::size_t, const std::nothrow_t&)`
-- `operator new[](std::size_t)`
-- `operator new[](std::size_t, const std::nothrow_t&)`
-- `operator delete(void*)`
-- `operator delete(void*, const std::nothrow_t&)`
-- `operator delete[](void*)`
-- `operator delete[](void*, const std::nothrow_t&)`
-- `operator delete(void*, std::size_t)`
-- `operator delete(void*, std::size_t, const std::nothrow_t&)`
-- `operator delete[](void*, std::size_t)`
-- `operator delete[](void*, std::size_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 definitions shall not be specified as `inline`. No
 diagnostic is required.
 #### Handler functions <a id="handler.functions">[[handler.functions]]</a>
-The C++standard library provides default versions of the following
-handler functions (Clause  [[language.support]]):
-- `unexpected_handler`
 - `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
 library as an argument to (respectively):
 - `set_new_handler`
-- `set_unexpected`
-- `set_terminate` subclauses  [[alloc.errors]], Storage allocation
-  errors, and  [[support.exception]], Exception handling.
 A C++program can get a pointer to the current handler function by
 calling the following functions:
 - `get_new_handler`
-- `get_unexpected`
 - `get_terminate`
 Calling the `set_*` and `get_*` functions shall not incur a data race. A
 call to any of the `set_*` functions shall synchronize with subsequent
 calls to the same `set_*` function and to the corresponding `get_*`
@@ -188,26 +237,26 @@ 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, the 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]],
- [[unexpected.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 subclause ([[allocator.requirements]],
-  [[container.requirements]], [[iterator.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.
@@ -228,37 +277,40 @@ the C++standard library, unless explicitly stated otherwise.
   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. 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. 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 `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.
-#### Shared objects and the library <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]]. 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.
-In particular, the program is required to ensure that completion of the
-constructor of any object of a class type defined in the standard
-library happens before any other member function invocation on that
-object and, unless otherwise specified, to ensure that completion of any
-member function invocation other than destruction on such an object
-happens before destruction of that object. This applies even to objects
-such as mutexes intended for thread synchronization.
 #### 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:*

 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
 - an explicit specialization of any member function template of a
   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.
 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:
 - macros
 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
+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
 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&)
+operator new(std::size_t, std::align_val_t, const std::nothrow_t&)
+```
+``` cpp
+operator delete(void*)
+operator delete(void*, std::size_t)
+operator delete(void*, std::align_val_t)
+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&)
+```
+``` 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 new[](std::size_t, std::align_val_t, const std::nothrow_t&)
+```
+``` cpp
+operator delete[](void*)
+operator delete[](void*, std::size_t)
+operator delete[](void*, std::align_val_t)
+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
 library as an argument to (respectively):
 - `set_new_handler`
+- `set_terminate`
+See also subclauses  [[alloc.errors]], Storage allocation errors, and
+[[support.exception]], Exception handling.
 A C++program can get a pointer to the current handler function by
 calling the following functions:
 - `get_new_handler`
 - `get_terminate`
 Calling the `set_*` and `get_*` functions shall not incur a data race. A
 call to any of the `set_*` functions shall synchronize with subsequent
 calls to the same `set_*` function and to the corresponding `get_*`
 #### 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.
   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. 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:*

Diff to HTML by rtfpessoa