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

Files changed (1) hide show

tmp/tmpm19ad_83/{from.md → to.md} +161 -149

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

@@ -4,13 +4,13 @@
 This section describes the constraints upon, and latitude of,
 implementations of the C++standard library.
 An implementation’s use of headers is discussed in  [[res.on.headers]],
-its use of macros in  [[res.on.macro.definitions]], global functions in
-[[global.functions]], member functions in  [[member.functions]], data
-race avoidance in  [[res.on.data.races]], access specifiers in
 [[protection.within.classes]], class derivation in  [[derivation]], and
 exceptions in  [[res.on.exception.handling]].
 #### Headers <a id="res.on.headers">[[res.on.headers]]</a>
@@ -23,12 +23,13 @@ headers.
 Certain types and macros are defined in more than one header. Every such
 entity shall be defined such that any header that defines it may be
 included after any other header that also defines it (
 [[basic.def.odr]]).
-The C standard headers ([[depr.c.headers]]) shall include only their
-corresponding C++standard header, as described in  [[headers]].
 #### Restrictions on macro definitions <a id="res.on.macro.definitions">[[res.on.macro.definitions]]</a>
 The names and global function signatures described in  [[contents]] are
 reserved to the implementation.
@@ -36,66 +37,71 @@ reserved to the implementation.
 All object-like macros defined by the C standard library and described
 in this Clause as expanding to integral constant expressions are also
 suitable for use in `#if` preprocessing directives, unless explicitly
 stated otherwise.
-#### Global and non-member functions <a id="global.functions">[[global.functions]]</a>
-It is unspecified whether any global or non-member functions in the
-C++standard library are defined as `inline` ([[dcl.fct.spec]]).
-A call to a global or non-member function signature described in
-Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]]
-shall behave as if the implementation declared no additional global or
-non-member function signatures.[^27]
-An implementation shall not declare a global or non-member function
-signature with additional default arguments.
-Unless otherwise specified, global and non-member functions in the
-standard library shall not use functions from another namespace which
-are found through *argument-dependent name lookup* (
-[[basic.lookup.argdep]]). The phrase “unless otherwise specified” is
-intended to allow argument-dependent lookup in cases like that of
-`ostream_iterator::operator=` ([[ostream.iterator.ops]]):
 *Effects:*
 ``` cpp
 *out_stream << value;
 if (delim != 0)
   *out_stream << delim;
 return *this;
 ```
 #### Member functions <a id="member.functions">[[member.functions]]</a>
 It is unspecified whether any member functions in the C++standard
-library are defined as `inline` ([[dcl.fct.spec]]).
-An implementation may declare additional non-virtual member function
-signatures within a class:
-- by adding arguments with default values to a member function
-  signature; [^28] An implementation may not add arguments with default
-  values to virtual, global, or non-member functions.
-- by replacing a member function signature with default values by two or
-  more member function signatures with equivalent behavior; and
-- by adding a member function signature for a member function name.
-A call to a member function signature described in the C++standard
-library behaves as if the implementation declares no additional member
-function signatures.[^29]
-#### `constexpr` functions and constructors <a id="constexpr.functions">[[constexpr.functions]]</a>
-This standard explicitly requires that certain standard library
-functions are `constexpr` ([[dcl.constexpr]]). An implementation shall
-not declare any standard library function signature as `constexpr`
-except for those where it is explicitly required. Within any header that
-provides any non-defining declarations of `constexpr` functions or
-constructors an implementation shall provide corresponding definitions.
 #### Requirements for stable algorithms <a id="algorithm.stable">[[algorithm.stable]]</a>
 When the requirements for an algorithm state that it is “stable” without
 further elaboration, it means:
@@ -109,12 +115,12 @@ further elaboration, it means:
   original order) precede the elements from the second range (preserving
   their original order).
 #### Reentrancy <a id="reentrancy">[[reentrancy]]</a>
-Except where explicitly specified in this standard, it is
-*implementation-defined* which functions in the Standard C++ library may
 be recursively reentered.
 #### Data race avoidance <a id="res.on.data.races">[[res.on.data.races]]</a>
 This section specifies requirements that implementations shall meet to
@@ -131,36 +137,38 @@ via the function’s arguments, including `this`.
 A C++standard library function shall not directly or indirectly modify
 objects ([[intro.multithread]]) accessible by threads other than the
 current thread unless the objects are accessed directly or indirectly
 via the function’s non-const arguments, including `this`.
-This means, for example, that implementations can’t use a static object
-for internal purposes without synchronization because it could cause a
-data race even in programs that do not explicitly share objects between
-threads.
 A C++standard library function shall not access objects indirectly
 accessible via its arguments or via elements of its container arguments
 except by invoking functions required by its specification on those
 container elements.
 Operations on iterators obtained by calling a standard library container
 or string member function may access the underlying container, but shall
-not modify it. In particular, container operations that invalidate
 iterators conflict with operations on iterators associated with that
-container.
 Implementations may share their own internal objects between threads if
 the objects are not visible to users and are protected against data
 races.
 Unless otherwise specified, C++standard library functions shall perform
 all operations solely within the current thread if those operations have
 effects that are visible ([[intro.multithread]]) to users.
-This allows implementations to parallelize operations if there are no
-visible side effects.
 #### Protection within classes <a id="protection.within.classes">[[protection.within.classes]]</a>
 It is unspecified whether any function signature or class described in
 Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]] is
@@ -178,64 +186,74 @@ through a hierarchy of base classes with names reserved to the
 implementation.
 In any case:
 - Every base class described as `virtual` shall be virtual;
-- Every base class described as non-`virtual` shall not be virtual;
 - Unless explicitly stated otherwise, types with distinct names shall be
-  distinct types.[^30]
 #### Restrictions on exception handling <a id="res.on.exception.handling">[[res.on.exception.handling]]</a>
 Any of the functions defined in the C++standard library can report a
-failure by throwing an exception of a type described in its paragraph.
-An implementation may strengthen the *exception-specification* for a
-non-virtual function by adding a non-throwing *noexcept-specification*.
-A function may throw an object of a type not listed in its clause if its
-type is derived from a type named in the clause and would be caught by
-an exception handler for the base type.
-Functions from the C standard library shall not throw exceptions [^31]
 except when such a function calls a program-supplied function that
-throws an exception.[^32]
 Destructor operations defined in the C++standard library shall not throw
 exceptions. Every destructor in the C++standard library shall behave as
-if it had a non-throwing exception specification. Any other functions
-defined in the C++standard library that do not have an
-*exception-specification* may throw *implementation-defined* exceptions
-unless otherwise specified.[^33] An implementation may strengthen this
-implicit *exception-specification* by adding an explicit one.[^34]
 #### Restrictions on storage of pointers <a id="res.on.pointer.storage">[[res.on.pointer.storage]]</a>
 Objects constructed by the standard library that may hold a
 user-supplied pointer value or an integer of type `std::intptr_t` shall
 store such values in a traceable pointer location (
-[[basic.stc.dynamic.safety]]). Other libraries are strongly encouraged
-to do the same, since not doing so may result in accidental use of
-pointers that are not safely derived. Libraries that store pointers
-outside the user’s address space should make it appear that they are
-stored and retrieved from a traceable pointer location.
 #### Value of error codes <a id="value.error.codes">[[value.error.codes]]</a>
 Certain functions in the C++standard library report errors via a
 `std::error_code` ([[syserr.errcode.overview]]) object. That object’s
 `category()` member shall return `std::system_category()` for errors
 originating from the operating system, or a reference to an
 *implementation-defined* `error_category` object for errors originating
 elsewhere. The implementation shall define the possible values of
-`value()` for each of these error categories. For operating systems that
-are based on POSIX, implementations are encouraged to define the
-`std::system_category()` values as identical to the POSIX `errno`
-values, with additional values as defined by the operating system’s
-documentation. Implementations for operating systems that are not based
-on POSIX are encouraged to define values identical to the operating
-system’s values. For errors that do not originate from the operating
-system, the implementation may provide enums for the associated values.
 #### Moved-from state of library types <a id="lib.types.movedfrom">[[lib.types.movedfrom]]</a>
 Objects of types defined in the C++standard library may be moved from (
 [[class.copy]]). Move operations may be explicitly specified or
@@ -245,18 +263,21 @@ objects shall be placed in a valid but unspecified state.
 <!-- Link reference definitions -->
 [alg.c.library]: algorithms.md#alg.c.library
 [alg.sorting]: algorithms.md#alg.sorting
 [algorithm.stable]: #algorithm.stable
 [algorithms]: algorithms.md#algorithms
 [alloc.errors]: language.md#alloc.errors
 [allocator.requirements]: #allocator.requirements
 [allocator.traits]: utilities.md#allocator.traits
 [alt.headers]: #alt.headers
 [atomics]: atomics.md#atomics
 [bad.alloc]: language.md#bad.alloc
 [basic.def.odr]: basic.md#basic.def.odr
 [basic.fundamental]: basic.md#basic.fundamental
 [basic.link]: basic.md#basic.link
 [basic.lookup.argdep]: basic.md#basic.lookup.argdep
 [basic.scope.namespace]: basic.md#basic.scope.namespace
 [basic.start]: basic.md#basic.start
 [basic.stc.dynamic]: basic.md#basic.stc.dynamic
@@ -265,10 +286,11 @@ objects shall be placed in a valid but unspecified state.
 [bitmask.types]: #bitmask.types
 [byte.strings]: #byte.strings
 [c.locales]: localization.md#c.locales
 [c.strings]: strings.md#c.strings
 [character.seq]: #character.seq
 [class.copy]: special.md#class.copy
 [class.ctor]: special.md#class.ctor
 [class.dtor]: special.md#class.dtor
 [class.mem]: class.md#class.mem
 [class.mfct]: class.md#class.mfct
@@ -289,49 +311,50 @@ objects shall be placed in a valid but unspecified state.
 [cstdint]: language.md#cstdint
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
 [dcl.constexpr]: dcl.md#dcl.constexpr
 [dcl.fct.default]: dcl.md#dcl.fct.default
-[dcl.fct.spec]: dcl.md#dcl.fct.spec
 [dcl.init]: dcl.md#dcl.init
 [dcl.link]: dcl.md#dcl.link
 [definitions]: #definitions
-[defns.additional]: #defns.additional
 [depr]: future.md#depr
 [depr.c.headers]: future.md#depr.c.headers
 [derivation]: #derivation
 [derived.classes]: #derived.classes
 [description]: #description
-[destructible]: #destructible
 [diagnostics]: diagnostics.md#diagnostics
 [enumerated.types]: #enumerated.types
-[equalitycomparable]: #equalitycomparable
 [except]: except.md#except
 [expr.delete]: expr.md#expr.delete
 [expr.eq]: expr.md#expr.eq
 [expr.new]: expr.md#expr.new
 [expr.rel]: expr.md#expr.rel
 [extern.names]: #extern.names
 [extern.types]: #extern.types
 [function.objects]: utilities.md#function.objects
 [functions.within.classes]: #functions.within.classes
 [global.functions]: #global.functions
-[global.names]: #global.names
 [handler.functions]: #handler.functions
-[hash]: #hash
 [hash.requirements]: #hash.requirements
 [headers]: #headers
 [input.output]: input.md#input.output
 [intro.compliance]: intro.md#intro.compliance
 [intro.defs]: intro.md#intro.defs
 [intro.multithread]: intro.md#intro.multithread
 [intro.refs]: intro.md#intro.refs
 [iterator.requirements]: iterators.md#iterator.requirements
 [iterators]: iterators.md#iterators
 [language.support]: language.md#language.support
 [lex]: lex.md#lex
-[lex.key]: lex.md#lex.key
 [lex.phases]: lex.md#lex.phases
 [lib.types.movedfrom]: #lib.types.movedfrom
 [library]: #library
 [library.c]: #library.c
 [library.general]: #library.general
@@ -341,25 +364,27 @@ objects shall be placed in a valid but unspecified state.
 [member.functions]: #member.functions
 [meta]: utilities.md#meta
 [multibyte.strings]: #multibyte.strings
 [namespace.constraints]: #namespace.constraints
 [namespace.def]: dcl.md#namespace.def
 [namespace.posix]: #namespace.posix
 [namespace.std]: #namespace.std
 [namespace.udecl]: dcl.md#namespace.udecl
 [new.delete]: language.md#new.delete
 [new.handler]: language.md#new.handler
-[nullablepointer]: #nullablepointer
 [nullablepointer.requirements]: #nullablepointer.requirements
 [numeric.requirements]: numerics.md#numeric.requirements
 [numerics]: numerics.md#numerics
 [objects.within.classes]: #objects.within.classes
 [organization]: #organization
 [ostream.iterator.ops]: iterators.md#ostream.iterator.ops
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [protection.within.classes]: #protection.within.classes
 [re]: re.md#re
 [reentrancy]: #reentrancy
 [replacement.functions]: #replacement.functions
 [requirements]: #requirements
 [res.on.arguments]: #res.on.arguments
@@ -390,164 +415,151 @@ objects shall be placed in a valid but unspecified state.
 [support.start.term]: language.md#support.start.term
 [support.types]: language.md#support.types
 [swappable.requirements]: #swappable.requirements
 [syserr]: diagnostics.md#syserr
 [syserr.errcode.overview]: diagnostics.md#syserr.errcode.overview
 [tab:cpp.c.headers]: #tab:cpp.c.headers
 [tab:cpp.headers.freestanding]: #tab:cpp.headers.freestanding
 [tab:cpp.library.headers]: #tab:cpp.library.headers
 [tab:desc.var.def]: #tab:desc.var.def
 [tab:identifiers.special]: lex.md#tab:identifiers.special
 [tab:library.categories]: #tab:library.categories
 [tab:utilities.allocator.requirements]: #tab:utilities.allocator.requirements
 [temp.deduct.call]: temp.md#temp.deduct.call
 [template.bitset]: utilities.md#template.bitset
 [terminate.handler]: language.md#terminate.handler
 [thread]: thread.md#thread
 [type.descriptions]: #type.descriptions
 [type.descriptions.general]: #type.descriptions.general
-[unexpected.handler]: future.md#unexpected.handler
 [using]: #using
 [using.headers]: #using.headers
 [using.linkage]: #using.linkage
 [using.overview]: #using.overview
 [usrlit.suffix]: #usrlit.suffix
 [utilities]: utilities.md#utilities
 [utility]: utilities.md#utility
 [utility.arg.requirements]: #utility.arg.requirements
 [utility.requirements]: #utility.requirements
 [value.error.codes]: #value.error.codes
-[^1]: This definition is taken from POSIX.
-[^2]: To save space, items that do not apply to a Clause are omitted.
     For example, if a Clause does not specify any requirements, there
     will be no “Requirements” subclause.
-[^3]: Although in some cases the code given is unambiguously the optimum
     implementation.
-[^4]: To save space, items that do not apply to a class are omitted. For
     example, if a class does not specify any comparison functions, there
     will be no “Comparison functions” subclause.
-[^5]: To save space, items that do not apply to a function are omitted.
     For example, if a function does not specify any further
-    preconditions, there will be no “Requires” paragraph.
-[^6]: This simplifies the presentation of complexity requirements in
     some cases.
-[^7]: Examples from  [[utility.requirements]] include:
     `EqualityComparable`, `LessThanComparable`, `CopyConstructible`.
     Examples from  [[iterator.requirements]] include: `InputIterator`,
-    `ForwardIterator`, `Function`, `Predicate`.
-[^8]: Such as an integer type, with constant integer values (
     [[basic.fundamental]]).
-[^9]: Note that this definition differs from the definition in ISO C
-    7.1.1.
-[^10]: declared in `<clocale>` ([[c.locales]]).
-[^11]: Many of the objects manipulated by function signatures declared
-    in `<cstring>` ([[c.strings]]) are character sequences or NTBSs.
-    The size of some of these character sequences is limited by a length
     value, maintained separately from the character sequence.
-[^12]: A string literal, such as `"abc"`, is a static NTBS.
-[^13]: An NTBSthat contains characters only from the basic execution
     character set is also an NTMBS. Each multibyte character then
     consists of a single byte.
-[^14]: The C standard library headers (Annex  [[depr.c.headers]]) also
     define names within the global namespace, while the C++headers for C
     library facilities ([[headers]]) may also define names within the
     global namespace.
-[^15]: This gives implementers freedom to use inline namespaces to
     support multiple configurations of the library.
-[^16]: A header is not necessarily a source file, nor are the sequences
     delimited by `<` and `>` in header names necessarily valid source
     file names ([[cpp.include]]).
-[^17]: This disallows the practice, allowed in C, of providing a masking
     macro in addition to the function prototype. The only way to achieve
     equivalent inline behavior in C++is to provide a definition as an
     extern inline function.
-[^18]: In particular, including the standard header `<iso646.h>` or
     `<ciso646>` has no effect.
-[^19]: The `".h"` headers dump all their names into the global
     namespace, whereas the newer forms keep their names in namespace
     `std`. Therefore, the newer forms are the preferred forms for all
     uses except for C++programs which are intended to be strictly
     compatible with C.
-[^20]: This is the same as the Standard C library.
-[^21]: The only reliable way to declare an object or function signature
-    from the Standard C library is by including the header that declares
     it, notwithstanding the latitude granted in 7.1.4 of the C Standard.
-[^22]: Any library code that instantiates other library templates must
     be prepared to work adequately with any user-supplied specialization
-    that meets the minimum requirements of the Standard.
-[^23]: The list of such reserved names includes `errno`, declared or
     defined in `<cerrno>`.
-[^24]: The list of such reserved function signatures with external
     linkage includes `setjmp(jmp_buf)`, declared or defined in
     `<csetjmp>`, and `va_end(va_list)`, declared or defined in
     `<cstdarg>`.
-[^25]: The function signatures declared in `<cuchar>`, `<cwchar>`, and
     `<cwctype>` are always reserved, notwithstanding the restrictions
     imposed in subclause 4.5.1 of Amendment 1 to the C Standard for
     these headers.
-[^26]: These types are `clock_t`, `div_t`, `FILE`, `fpos_t`, `lconv`,
     `ldiv_t`, `mbstate_t`, `ptrdiff_t`, `sig_atomic_t`, `size_t`,
     `time_t`, `tm`, `va_list`, `wctrans_t`, `wctype_t`, and `wint_t`.
-[^27]: A valid C++program always calls the expected library global or
- non-member function. An implementation may also define additional
- global or non-member functions that would otherwise not be called by
-    a valid C++program.
-[^28]: Hence, the address of a member function of a class in the
-    C++standard library has an unspecified type.
-[^29]: A valid C++program always calls the expected library member
-    function, or one with equivalent behavior. An implementation may
-    also define additional member functions that would otherwise not be
-    called by a valid C++program.
-[^30]: There is an implicit exception to this rule for types that are
     described as synonyms for basic integral types, such as `size_t` (
     [[support.types]]) and `streamoff` ([[stream.types]]).
-[^31]: That is, the C library functions can all be treated as if they
     are marked `noexcept`. This allows implementations to make
     performance optimizations based on the absence of exceptions at
     runtime.
-[^32]: The functions `qsort()` and `bsearch()` ([[alg.c.library]]) meet
     this condition.
-[^33]: In particular, they can report a failure to allocate storage by
     throwing an exception of type `bad_alloc`, or a class derived from
-    `bad_alloc` ([[bad.alloc]]). Library implementations should report
-    errors by throwing exceptions of or derived from the standard
-    exception classes ([[bad.alloc]], [[support.exception]],
-    [[std.exceptions]]).
-[^34]: That is, an implementation may provide an explicit
-    *exception-specification* that defines the subset of “any”
-    exceptions thrown by that function. This implies that the
-    implementation may list implementation-defined types in such an
-    *exception-specification*.

 This section describes the constraints upon, and latitude of,
 implementations of the C++standard library.
 An implementation’s use of headers is discussed in  [[res.on.headers]],
+its use of macros in  [[res.on.macro.definitions]], non-member functions
+in  [[global.functions]], member functions in  [[member.functions]],
+data race avoidance in  [[res.on.data.races]], access specifiers in
 [[protection.within.classes]], class derivation in  [[derivation]], and
 exceptions in  [[res.on.exception.handling]].
 #### Headers <a id="res.on.headers">[[res.on.headers]]</a>
 Certain types and macros are defined in more than one header. Every such
 entity shall be defined such that any header that defines it may be
 included after any other header that also defines it (
 [[basic.def.odr]]).
+The C standard library headers ([[depr.c.headers]]) shall include only
+their corresponding C++standard library header, as described in
+[[headers]].
 #### Restrictions on macro definitions <a id="res.on.macro.definitions">[[res.on.macro.definitions]]</a>
 The names and global function signatures described in  [[contents]] are
 reserved to the implementation.
 All object-like macros defined by the C standard library and described
 in this Clause as expanding to integral constant expressions are also
 suitable for use in `#if` preprocessing directives, unless explicitly
 stated otherwise.
+#### Non-member functions <a id="global.functions">[[global.functions]]</a>
+It is unspecified whether any non-member functions in the C++standard
+library are defined as `inline` ([[dcl.inline]]).
+A call to a non-member function signature described in Clauses
+[[language.support]] through  [[thread]] and Annex  [[depr]] shall
+behave as if the implementation declared no additional non-member
+function signatures.[^26]
+An implementation shall not declare a non-member function signature with
+additional default arguments.
+Unless otherwise specified, calls made by functions in the standard
+library to non-operator, non-member functions do not use functions from
+another namespace which are found through *argument-dependent name
+lookup* ([[basic.lookup.argdep]]).
+[*Note 1*:
+The phrase “unless otherwise specified” applies to cases such as the
+swappable with requirements ([[swappable.requirements]]). The exception
+for overloaded operators allows argument-dependent lookup in cases like
+that of `ostream_iterator::operator=` ([[ostream.iterator.ops]]):
 *Effects:*
 ``` cpp
 *out_stream << value;
 if (delim != 0)
   *out_stream << delim;
 return *this;
 ```
+— *end note*]
 #### Member functions <a id="member.functions">[[member.functions]]</a>
 It is unspecified whether any member functions in the C++standard
+library are defined as `inline` ([[dcl.inline]]).
+For a non-virtual member function described in the C++standard library,
+an implementation may declare a different set of member function
+signatures, provided that any call to the member function that would
+select an overload from the set of declarations described in this
+International Standard behaves as if that overload were selected.
+[*Note 1*: For instance, an implementation may add parameters with
+default values, or replace a member function with default arguments with
+two or more member functions with equivalent behavior, or add additional
+signatures for a member function name. — *end note*]
+#### Constexpr functions and constructors <a id="constexpr.functions">[[constexpr.functions]]</a>
+This International Standard explicitly requires that certain standard
+library functions are `constexpr` ([[dcl.constexpr]]). An
+implementation shall not declare any standard library function signature
+as `constexpr` except for those where it is explicitly required. Within
+any header that provides any non-defining declarations of constexpr
+functions or constructors an implementation shall provide corresponding
+definitions.
 #### Requirements for stable algorithms <a id="algorithm.stable">[[algorithm.stable]]</a>
 When the requirements for an algorithm state that it is “stable” without
 further elaboration, it means:
   original order) precede the elements from the second range (preserving
   their original order).
 #### Reentrancy <a id="reentrancy">[[reentrancy]]</a>
+Except where explicitly specified in this International Standard, it is
+*implementation-defined* which functions in the C++standard library may
 be recursively reentered.
 #### Data race avoidance <a id="res.on.data.races">[[res.on.data.races]]</a>
 This section specifies requirements that implementations shall meet to
 A C++standard library function shall not directly or indirectly modify
 objects ([[intro.multithread]]) accessible by threads other than the
 current thread unless the objects are accessed directly or indirectly
 via the function’s non-const arguments, including `this`.
+[*Note 1*: This means, for example, that implementations can’t use a
+static object for internal purposes without synchronization because it
+could cause a data race even in programs that do not explicitly share
+objects between threads. — *end note*]
 A C++standard library function shall not access objects indirectly
 accessible via its arguments or via elements of its container arguments
 except by invoking functions required by its specification on those
 container elements.
 Operations on iterators obtained by calling a standard library container
 or string member function may access the underlying container, but shall
+not modify it.
+[*Note 2*: In particular, container operations that invalidate
 iterators conflict with operations on iterators associated with that
+container. — *end note*]
 Implementations may share their own internal objects between threads if
 the objects are not visible to users and are protected against data
 races.
 Unless otherwise specified, C++standard library functions shall perform
 all operations solely within the current thread if those operations have
 effects that are visible ([[intro.multithread]]) to users.
+[*Note 3*: This allows implementations to parallelize operations if
+there are no visible side effects. — *end note*]
 #### Protection within classes <a id="protection.within.classes">[[protection.within.classes]]</a>
 It is unspecified whether any function signature or class described in
 Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]] is
 implementation.
 In any case:
 - Every base class described as `virtual` shall be virtual;
+- Every base class not specified as `virtual` shall not be virtual;
 - Unless explicitly stated otherwise, types with distinct names shall be
+  distinct types.[^27]
+All types specified in the C++standard library shall be non-`final`
+types unless otherwise specified.
 #### Restrictions on exception handling <a id="res.on.exception.handling">[[res.on.exception.handling]]</a>
 Any of the functions defined in the C++standard library can report a
+failure by throwing an exception of a type described in its *Throws:*
+paragraph, or of a type derived from a type named in the *Throws:*
+paragraph that would be caught by an exception handler for the base
+type.
+Functions from the C standard library shall not throw exceptions [^28]
 except when such a function calls a program-supplied function that
+throws an exception.[^29]
 Destructor operations defined in the C++standard library shall not throw
 exceptions. Every destructor in the C++standard library shall behave as
+if it had a non-throwing exception specification.
+Functions defined in the C++standard library that do not have a
+*Throws:* paragraph but do have a potentially-throwing exception
+specification may throw *implementation-defined* exceptions. [^30]
+Implementations should report errors by throwing exceptions of or
+derived from the standard exception classes ([[bad.alloc]],
+[[support.exception]], [[std.exceptions]]).
+An implementation may strengthen the exception specification for a
+non-virtual function by adding a non-throwing exception specification.
 #### Restrictions on storage of pointers <a id="res.on.pointer.storage">[[res.on.pointer.storage]]</a>
 Objects constructed by the standard library that may hold a
 user-supplied pointer value or an integer of type `std::intptr_t` shall
 store such values in a traceable pointer location (
+[[basic.stc.dynamic.safety]]).
+[*Note 1*: Other libraries are strongly encouraged to do the same,
+since not doing so may result in accidental use of pointers that are not
+safely derived. Libraries that store pointers outside the user’s address
+space should make it appear that they are stored and retrieved from a
+traceable pointer location. — *end note*]
 #### Value of error codes <a id="value.error.codes">[[value.error.codes]]</a>
 Certain functions in the C++standard library report errors via a
 `std::error_code` ([[syserr.errcode.overview]]) object. That object’s
 `category()` member shall return `std::system_category()` for errors
 originating from the operating system, or a reference to an
 *implementation-defined* `error_category` object for errors originating
 elsewhere. The implementation shall define the possible values of
+`value()` for each of these error categories.
+[*Example 1*: For operating systems that are based on POSIX,
+implementations are encouraged to define the `std::system_category()`
+values as identical to the POSIX `errno` values, with additional values
+as defined by the operating system’s documentation. Implementations for
+operating systems that are not based on POSIX are encouraged to define
+values identical to the operating system’s values. For errors that do
+not originate from the operating system, the implementation may provide
+enums for the associated values. — *end example*]
 #### Moved-from state of library types <a id="lib.types.movedfrom">[[lib.types.movedfrom]]</a>
 Objects of types defined in the C++standard library may be moved from (
 [[class.copy]]). Move operations may be explicitly specified or
 <!-- Link reference definitions -->
 [alg.c.library]: algorithms.md#alg.c.library
 [alg.sorting]: algorithms.md#alg.sorting
 [algorithm.stable]: #algorithm.stable
 [algorithms]: algorithms.md#algorithms
+[algorithms.requirements]: algorithms.md#algorithms.requirements
 [alloc.errors]: language.md#alloc.errors
 [allocator.requirements]: #allocator.requirements
+[allocator.requirements.completeness]: #allocator.requirements.completeness
 [allocator.traits]: utilities.md#allocator.traits
 [alt.headers]: #alt.headers
 [atomics]: atomics.md#atomics
 [bad.alloc]: language.md#bad.alloc
 [basic.def.odr]: basic.md#basic.def.odr
 [basic.fundamental]: basic.md#basic.fundamental
+[basic.life]: basic.md#basic.life
 [basic.link]: basic.md#basic.link
 [basic.lookup.argdep]: basic.md#basic.lookup.argdep
 [basic.scope.namespace]: basic.md#basic.scope.namespace
 [basic.start]: basic.md#basic.start
 [basic.stc.dynamic]: basic.md#basic.stc.dynamic
 [bitmask.types]: #bitmask.types
 [byte.strings]: #byte.strings
 [c.locales]: localization.md#c.locales
 [c.strings]: strings.md#c.strings
 [character.seq]: #character.seq
+[class.conv.ctor]: special.md#class.conv.ctor
 [class.copy]: special.md#class.copy
 [class.ctor]: special.md#class.ctor
 [class.dtor]: special.md#class.dtor
 [class.mem]: class.md#class.mem
 [class.mfct]: class.md#class.mfct
 [cstdint]: language.md#cstdint
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
 [dcl.constexpr]: dcl.md#dcl.constexpr
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.init]: dcl.md#dcl.init
+[dcl.init.list]: dcl.md#dcl.init.list
+[dcl.inline]: dcl.md#dcl.inline
 [dcl.link]: dcl.md#dcl.link
 [definitions]: #definitions
 [depr]: future.md#depr
 [depr.c.headers]: future.md#depr.c.headers
+[depr.cstdalign.syn]: future.md#depr.cstdalign.syn
+[depr.cstdbool.syn]: future.md#depr.cstdbool.syn
 [derivation]: #derivation
 [derived.classes]: #derived.classes
 [description]: #description
 [diagnostics]: diagnostics.md#diagnostics
 [enumerated.types]: #enumerated.types
 [except]: except.md#except
+[expos.only.types]: #expos.only.types
+[expr.cond]: expr.md#expr.cond
+[expr.const]: expr.md#expr.const
 [expr.delete]: expr.md#expr.delete
 [expr.eq]: expr.md#expr.eq
 [expr.new]: expr.md#expr.new
 [expr.rel]: expr.md#expr.rel
 [extern.names]: #extern.names
 [extern.types]: #extern.types
 [function.objects]: utilities.md#function.objects
 [functions.within.classes]: #functions.within.classes
 [global.functions]: #global.functions
 [handler.functions]: #handler.functions
 [hash.requirements]: #hash.requirements
 [headers]: #headers
 [input.output]: input.md#input.output
 [intro.compliance]: intro.md#intro.compliance
 [intro.defs]: intro.md#intro.defs
 [intro.multithread]: intro.md#intro.multithread
 [intro.refs]: intro.md#intro.refs
 [iterator.requirements]: iterators.md#iterator.requirements
+[iterator.requirements.general]: iterators.md#iterator.requirements.general
 [iterators]: iterators.md#iterators
 [language.support]: language.md#language.support
 [lex]: lex.md#lex
 [lex.phases]: lex.md#lex.phases
 [lib.types.movedfrom]: #lib.types.movedfrom
 [library]: #library
 [library.c]: #library.c
 [library.general]: #library.general
 [member.functions]: #member.functions
 [meta]: utilities.md#meta
 [multibyte.strings]: #multibyte.strings
 [namespace.constraints]: #namespace.constraints
 [namespace.def]: dcl.md#namespace.def
+[namespace.future]: #namespace.future
 [namespace.posix]: #namespace.posix
 [namespace.std]: #namespace.std
 [namespace.udecl]: dcl.md#namespace.udecl
 [new.delete]: language.md#new.delete
 [new.handler]: language.md#new.handler
 [nullablepointer.requirements]: #nullablepointer.requirements
 [numeric.requirements]: numerics.md#numeric.requirements
 [numerics]: numerics.md#numerics
 [objects.within.classes]: #objects.within.classes
 [organization]: #organization
 [ostream.iterator.ops]: iterators.md#ostream.iterator.ops
+[over.literal]: over.md#over.literal
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [protection.within.classes]: #protection.within.classes
+[random.access.iterators]: iterators.md#random.access.iterators
 [re]: re.md#re
 [reentrancy]: #reentrancy
 [replacement.functions]: #replacement.functions
 [requirements]: #requirements
 [res.on.arguments]: #res.on.arguments
 [support.start.term]: language.md#support.start.term
 [support.types]: language.md#support.types
 [swappable.requirements]: #swappable.requirements
 [syserr]: diagnostics.md#syserr
 [syserr.errcode.overview]: diagnostics.md#syserr.errcode.overview
+[tab:c.annex.k.names]: #tab:c.annex.k.names
+[tab:copyassignable]: #tab:copyassignable
 [tab:cpp.c.headers]: #tab:cpp.c.headers
 [tab:cpp.headers.freestanding]: #tab:cpp.headers.freestanding
 [tab:cpp.library.headers]: #tab:cpp.library.headers
 [tab:desc.var.def]: #tab:desc.var.def
+[tab:destructible]: #tab:destructible
+[tab:equalitycomparable]: #tab:equalitycomparable
+[tab:hash]: #tab:hash
 [tab:identifiers.special]: lex.md#tab:identifiers.special
 [tab:library.categories]: #tab:library.categories
+[tab:moveassignable]: #tab:moveassignable
+[tab:nullablepointer]: #tab:nullablepointer
 [tab:utilities.allocator.requirements]: #tab:utilities.allocator.requirements
 [temp.deduct.call]: temp.md#temp.deduct.call
 [template.bitset]: utilities.md#template.bitset
 [terminate.handler]: language.md#terminate.handler
 [thread]: thread.md#thread
 [type.descriptions]: #type.descriptions
 [type.descriptions.general]: #type.descriptions.general
 [using]: #using
 [using.headers]: #using.headers
 [using.linkage]: #using.linkage
 [using.overview]: #using.overview
 [usrlit.suffix]: #usrlit.suffix
 [utilities]: utilities.md#utilities
 [utility]: utilities.md#utility
 [utility.arg.requirements]: #utility.arg.requirements
 [utility.requirements]: #utility.requirements
 [value.error.codes]: #value.error.codes
+[zombie.names]: #zombie.names
+[^1]: To save space, items that do not apply to a Clause are omitted.
     For example, if a Clause does not specify any requirements, there
     will be no “Requirements” subclause.
+[^2]: Although in some cases the code given is unambiguously the optimum
     implementation.
+[^3]: To save space, items that do not apply to a class are omitted. For
     example, if a class does not specify any comparison functions, there
     will be no “Comparison functions” subclause.
+[^4]: To save space, items that do not apply to a function are omitted.
     For example, if a function does not specify any further
+    preconditions, there will be no *Requires:* paragraph.
+[^5]: This simplifies the presentation of complexity requirements in
     some cases.
+[^6]: Examples from  [[utility.requirements]] include:
     `EqualityComparable`, `LessThanComparable`, `CopyConstructible`.
     Examples from  [[iterator.requirements]] include: `InputIterator`,
+    `ForwardIterator`.
+[^7]: Such as an integer type, with constant integer values (
     [[basic.fundamental]]).
+[^8]: declared in `<clocale>` ([[c.locales]]).
+[^9]: Many of the objects manipulated by function signatures declared in
+    `<cstring>` ([[c.strings]]) are character sequences or NTBSs. The
+    size of some of these character sequences is limited by a length
     value, maintained separately from the character sequence.
+[^10]: A string literal, such as `"abc"`, is a static NTBS.
+[^11]: An NTBSthat contains characters only from the basic execution
     character set is also an NTMBS. Each multibyte character then
     consists of a single byte.
+[^12]: The C standard library headers (Annex  [[depr.c.headers]]) also
     define names within the global namespace, while the C++headers for C
     library facilities ([[headers]]) may also define names within the
     global namespace.
+[^13]: This gives implementers freedom to use inline namespaces to
     support multiple configurations of the library.
+[^14]: A header is not necessarily a source file, nor are the sequences
     delimited by `<` and `>` in header names necessarily valid source
     file names ([[cpp.include]]).
+[^15]: It is intentional that there is no C++header for any of these C
+    headers: `<stdatomic.h>`, `<stdnoreturn.h>`, `<threads.h>`.
+[^16]: This disallows the practice, allowed in C, of providing a masking
     macro in addition to the function prototype. The only way to achieve
     equivalent inline behavior in C++is to provide a definition as an
     extern inline function.
+[^17]: In particular, including the standard header `<iso646.h>` or
     `<ciso646>` has no effect.
+[^18]: The `".h"` headers dump all their names into the global
     namespace, whereas the newer forms keep their names in namespace
     `std`. Therefore, the newer forms are the preferred forms for all
     uses except for C++programs which are intended to be strictly
     compatible with C.
+[^19]: This is the same as the C standard library.
+[^20]: The only reliable way to declare an object or function signature
+    from the C standard library is by including the header that declares
     it, notwithstanding the latitude granted in 7.1.4 of the C Standard.
+[^21]: Any library code that instantiates other library templates must
     be prepared to work adequately with any user-supplied specialization
+    that meets the minimum requirements of this International Standard.
+[^22]: The list of such reserved names includes `errno`, declared or
     defined in `<cerrno>`.
+[^23]: The list of such reserved function signatures with external
     linkage includes `setjmp(jmp_buf)`, declared or defined in
     `<csetjmp>`, and `va_end(va_list)`, declared or defined in
     `<cstdarg>`.
+[^24]: The function signatures declared in `<cuchar>`, `<cwchar>`, and
     `<cwctype>` are always reserved, notwithstanding the restrictions
     imposed in subclause 4.5.1 of Amendment 1 to the C Standard for
     these headers.
+[^25]: These types are `clock_t`, `div_t`, `FILE`, `fpos_t`, `lconv`,
     `ldiv_t`, `mbstate_t`, `ptrdiff_t`, `sig_atomic_t`, `size_t`,
     `time_t`, `tm`, `va_list`, `wctrans_t`, `wctype_t`, and `wint_t`.
+[^26]: A valid C++program always calls the expected library non-member
+    function. An implementation may also define additional non-member
+    functions that would otherwise not be called by a valid C++program.
+[^27]: There is an implicit exception to this rule for types that are
     described as synonyms for basic integral types, such as `size_t` (
     [[support.types]]) and `streamoff` ([[stream.types]]).
+[^28]: That is, the C library functions can all be treated as if they
     are marked `noexcept`. This allows implementations to make
     performance optimizations based on the absence of exceptions at
     runtime.
+[^29]: The functions `qsort()` and `bsearch()` ([[alg.c.library]]) meet
     this condition.
+[^30]: In particular, they can report a failure to allocate storage by
     throwing an exception of type `bad_alloc`, or a class derived from
+    `bad_alloc` ([[bad.alloc]]).

Diff to HTML by rtfpessoa