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

Files changed (1) hide show

tmp/tmplmh2jwky/{from.md → to.md} +732 -289

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

@@ -1,23 +1,27 @@
 ## Library-wide requirements <a id="requirements">[[requirements]]</a>
-This subclause specifies requirements that apply to the entire C++
-standard library. [[support]] through [[thread]] and [[depr]] specify
-the requirements of individual entities within the library.
 Requirements specified in terms of interactions between threads do not
 apply to programs having only a single thread of execution.
-Within this subclause, [[organization]] describes the library’s contents
-and organization, [[using]] describes how well-formed C++ programs gain
-access to library entities, [[utility.requirements]] describes
-constraints on types and functions used with the C++ standard library,
-[[constraints]] describes constraints on well-formed C++ programs, and
-[[conforming]] describes constraints on conforming implementations.
 ### Library contents and organization <a id="organization">[[organization]]</a>
 [[contents]] describes the entities and macros defined in the C++
 standard library. [[headers]] lists the standard library headers and
 some constraints on those headers. [[compliance]] lists requirements for
 a freestanding implementation of the C++ standard library.
@@ -27,19 +31,40 @@ The C++ standard library provides definitions for the entities and
 macros described in the synopses of the C++ standard library headers
 [[headers]], unless otherwise specified.
 All library entities except `operator new` and `operator delete` are
 defined within the namespace `std` or namespaces nested within namespace
-`std`.[^12] It is unspecified whether names declared in a specific
-namespace are declared directly in that namespace or in an inline
-namespace inside that namespace.[^13]
-Whenever a name `x` defined in the standard library is mentioned, the
-name `x` is assumed to be fully qualified as `::std::x`, unless
-explicitly described otherwise. For example, if the *Effects:* element
-for library function `F` is described as calling library function `G`,
-the function `::std::G` is meant.
 #### Headers <a id="headers">[[headers]]</a>
 Each element of the C++ standard library is declared or defined (as
 appropriate) in a *header*.[^14]
@@ -53,12 +78,12 @@ headers shown in [[headers.cpp.c]]. [^15]
 The headers listed in [[headers.cpp]], or, for a freestanding
 implementation, the subset of such headers that are provided by the
 implementation, are collectively known as the
 *importable C++ library headers*.
-[*Note 1*: Importable C++ library headers can be imported as module
-units [[module.import]]. — *end note*]
 [*Example 1*:
 ``` cpp
 import <vector>;                // imports the <vector> header unit
@@ -90,12 +115,12 @@ Names that are defined as functions in C shall be defined as functions
 in the C++ standard library.[^16]
 Identifiers that are keywords or operators in C++ shall not be defined
 as macros in C++ standard library headers.[^17]
-[[depr.c.headers]], C standard library headers, describes the effects of
-using the `name.h` (C header) form in a C++ program.[^18]
 Annex K of the C standard describes a large number of functions, with
 associated types and macros, which “promote safer, more secure
 programming” than many of the traditional C library functions. The names
 of the functions have a suffix of `_s`; most of them provide the same
@@ -107,13 +132,54 @@ global namespace. (None of them is declared in namespace `std`.)
 [[c.annex.k.names]] lists the Annex K names that may be declared in some
 header. These names are also subject to the restrictions of
 [[macro.names]].
 #### Freestanding implementations <a id="compliance">[[compliance]]</a>
-Two kinds of implementations are defined: *hosted* and *freestanding*
 [[intro.compliance]]; the kind of the implementation is
 *implementation-defined*. For a hosted implementation, this document
 describes the set of available headers.
 A freestanding implementation has an *implementation-defined* set of
@@ -121,39 +187,39 @@ headers. This set shall include at least the headers shown in
 [[headers.cpp.fs]].
 **Table: C++ headers for freestanding implementations** <a id="headers.cpp.fs">[headers.cpp.fs]</a>
 | Subclause              |                                  | Header                                           |
-| ---------------------- | ------------------------- | ------------------------------------------------ |
-| [[support.types]]      | Types                     | `<cstddef>`                                      |
 | [[support.limits]]     | Implementation properties        | `<cfloat>`, `<climits>`, `<limits>`, `<version>` |
-| [[cstdint]] | Integer types | `<cstdint>`                                      |
 | [[support.start.term]] | Start and termination            | `<cstdlib>`                                      |
 | [[support.dynamic]]    | Dynamic memory management        | `<new>`                                          |
 | [[support.rtti]]       | Type identification              | `<typeinfo>`                                     |
 | [[support.srcloc]]     | Source location                  | `<source_location>`                              |
 | [[support.exception]]  | Exception handling               | `<exception>`                                    |
 | [[support.initlist]]   | Initializer lists                | `<initializer_list>`                             |
 | [[cmp]]                | Comparisons                      | `<compare>`                                      |
 | [[support.coroutine]]  | Coroutines support               | `<coroutine>`                                    |
 | [[support.runtime]]    | Other runtime support            | `<cstdarg>`                                      |
 | [[concepts]]           | Concepts library                 | `<concepts>`                                     |
-| [[meta]] | Type traits | `<type_traits>`                                  |
 | [[bit]]                | Bit manipulation                 | `<bit>`                                          |
 | [[atomics]]            | Atomics                          | `<atomic>`                                       |
-The supplied version of the header `<cstdlib>` shall declare at least
-the functions `abort`, `atexit`, `at_quick_exit`, `exit`, and
-`quick_exit` [[support.start.term]]. The supplied version of the header
-`<atomic>` shall meet the same requirements as for a hosted
-implementation except that support for always lock-free integral atomic
-types [[atomics.lockfree]] is *implementation-defined*, and whether or
-not the type aliases `atomic_signed_lock_free` and
-`atomic_unsigned_lock_free` are defined [[atomics.alias]] is
-*implementation-defined*. The other headers listed in this table shall
-meet the same requirements as for a hosted implementation.
 ### Using the library <a id="using">[[using]]</a>
 #### Overview <a id="using.overview">[[using.overview]]</a>
@@ -199,10 +265,12 @@ program are included in the program prior to program startup.
 See also replacement functions [[replacement.functions]], runtime
 changes [[handler.functions]].
 ### Requirements on types and expressions <a id="utility.requirements">[[utility.requirements]]</a>
 [[utility.arg.requirements]] describes requirements on types and
 expressions used to instantiate templates defined in the C++ standard
 library. [[swappable.requirements]] describes the requirements on
 swappable types and swappable expressions.
 [[nullablepointer.requirements]] describes the requirements on
@@ -214,33 +282,38 @@ allocators.
 #### Template argument requirements <a id="utility.arg.requirements">[[utility.arg.requirements]]</a>
 The template definitions in the C++ standard library refer to various
 named requirements whose details are set out in Tables
 [[tab:cpp17.equalitycomparable]]– [[tab:cpp17.destructible]]. In these
-tables, `T` is an object or reference type to be supplied by a C++
-program instantiating a template; `a`, `b`, and `c` are values of type
-(possibly `const`) `T`; `s` and `t` are modifiable lvalues of type `T`;
-`u` denotes an identifier; `rv` is an rvalue of type `T`; and `v` is an
-lvalue of type (possibly `const`) `T` or an rvalue of type `const T`.
 In general, a default constructor is not required. Certain container
 class member function signatures specify `T()` as a default argument.
 `T()` shall be a well-defined expression [[dcl.init]] if one of those
 signatures is called using the default argument [[dcl.fct.default]].
 **Table: Cpp17EqualityComparable requirements** <a id="cpp17.equalitycomparable">[cpp17.equalitycomparable]</a>
 | Expression | Return type |
 | ---------- | ----------- |
-| `a == b`   | convertible to `bool` | `==` is an equivalence relation, that is, it has the following properties: For all `a`, `a == a`.; If `a == b`, then `b == a`.; If `a == b` and `b == c`, then `a == c`. |
 **Table: Cpp17LessThanComparable requirements** <a id="cpp17.lessthancomparable">[cpp17.lessthancomparable]</a>
 | Expression | Return type                                 | Requirement                                            |
-| ---------- | --------------------- | ------------------------------------------------------ |
-| `a < b`    | convertible to `bool` | `<` is a strict weak ordering relation [[alg.sorting]] |
 **Table: Cpp17DefaultConstructible requirements** <a id="cpp17.defaultconstructible">[cpp17.defaultconstructible]</a>
 | Expression     | Post-condition                                                      |
@@ -248,37 +321,49 @@ signatures is called using the default argument [[dcl.fct.default]].
 | `T t;`         | object `t` is default-initialized                                   |
 | `T u{};`       | object `u` is value-initialized or aggregate-initialized            |
 | `T()`<br>`T{}` | an object of type `T` is value-initialized or aggregate-initialized |
-[*Note 1*: `rv` must still meet the requirements of the library
-component that is using it. The operations listed in those requirements
-must work as specified whether `rv` has been moved from or
-not. — *end note*]
 **Table: Cpp17CopyConstructible requirements (in addition to Cpp17MoveConstructible)** <a id="cpp17.copyconstructible">[cpp17.copyconstructible]</a>
 | Expression | Post-condition                                            |
 | ---------- | --------------------------------------------------------- |
 | `T u = v;` | the value of `v` is unchanged and is equivalent to ` u`   |
 | `T(v)`     | the value of `v` is unchanged and is equivalent to `T(v)` |
-[*Note 2*:  `rv` must still meet the requirements of the library
-component that is using it, whether or not `t` and `rv` refer to the
-same object. The operations listed in those requirements must work as
-specified whether `rv` has been moved from or not. — *end note*]
 **Table: Cpp17CopyAssignable requirements (in addition to Cpp17MoveAssignable)** <a id="cpp17.copyassignable">[cpp17.copyassignable]</a>
 | Expression | Return type | Return value | Post-condition                                          |
 | ---------- | ----------- | ------------ | ------------------------------------------------------- |
 | `t = v`    | `T&`        | `t`          | `t` is equivalent to `v`, the value of `v` is unchanged |
-[*Note 3*: Array types and non-object types are not
-*Cpp17Destructible*. — *end note*]
 #### Swappable requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
 This subclause provides definitions for swappable types and expressions.
 In these definitions, let `t` denote an expression of type `T`, and let
@@ -312,44 +397,48 @@ swappable requirement includes the header `<utility>` to ensure an
 appropriate evaluation context. — *end note*]
 An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
 with any rvalue or lvalue, respectively, of type `T`.
 A type `X` meeting any of the iterator requirements
 [[iterator.requirements]] meets the *Cpp17ValueSwappable* requirements
 if, for any dereferenceable object `x` of type `X`, `*x` is swappable.
 [*Example 1*:
 User code can ensure that the evaluation of `swap` calls is performed in
 an appropriate context under the various conditions as follows:
 ``` cpp
 #include <utility>
-// Requires: std::forward<T>(t) shall be swappable with std::forward<U>(u).
 template<class T, class U>
 void value_swap(T&& t, U&& u) {
   using std::swap;
-  swap(std::forward<T>(t), std::forward<U>(u)); // OK: uses ``swappable with'' conditions
                                                 // for rvalues and lvalues
 }
-// Requires: lvalues of T shall be swappable.
 template<class T>
 void lv_swap(T& t1, T& t2) {
   using std::swap;
-  swap(t1, t2);                                 // OK: uses swappable conditions for lvalues of type T
 }
 namespace N {
   struct A { int m; };
   struct Proxy { A* a; };
   Proxy proxy(A& a) { return Proxy{ &a }; }
   void swap(A& x, Proxy p) {
-    std::swap(x.m, p.a->m);                     // OK: uses context equivalent to swappable
                                                 // conditions for fundamental types
   }
   void swap(Proxy p, A& x) { swap(x, p); }      // satisfy symmetry constraint
 }
@@ -370,22 +459,21 @@ int main() {
 A *Cpp17NullablePointer* type is a pointer-like type that supports null
 values. A type `P` meets the *Cpp17NullablePointer* requirements if:
 - `P` meets the *Cpp17EqualityComparable*, *Cpp17DefaultConstructible*,
-  *Cpp17CopyConstructible*, *Cpp17CopyAssignable*, and
   *Cpp17Destructible* requirements,
-- lvalues of type `P` are swappable [[swappable.requirements]],
 - the expressions shown in [[cpp17.nullablepointer]] are valid and have
   the indicated semantics, and
 - `P` meets all the other requirements of this subclause.
 A value-initialized object of type `P` produces the null value of the
 type. The null value shall be equivalent only to itself. A
 default-initialized object of type `P` may have an indeterminate value.
-[*Note 1*: Operations involving indeterminate values may cause
 undefined behavior. — *end note*]
 An object `p` of type `P` can be contextually converted to `bool`
 [[conv]]. The effect shall be as if `p != nullptr` had been evaluated in
 place of `p`.
@@ -393,25 +481,25 @@ place of `p`.
 No operation which is part of the *Cpp17NullablePointer* requirements
 shall exit via an exception.
 In [[cpp17.nullablepointer]], `u` denotes an identifier, `t` denotes a
 non-`const` lvalue of type `P`, `a` and `b` denote values of type
-(possibly `const`) `P`, and `np` denotes a value of type (possibly
-`const`) `std::nullptr_t`.
 **Table: Cpp17NullablePointer requirements** <a id="cpp17.nullablepointer">[cpp17.nullablepointer]</a>
 | Expression     | Return type                                                               | Operational semantics       |
-| -------------- | ---------------------------------- | --------------------------- |
 | `P u(np);`<br> |                                                                           | Ensures: `u == nullptr`     |
 | `P u = np;`    |                                                                           |                             |
 | `P(np)`        |                                                                           | Ensures: `P(np) == nullptr` |
 | `t = np`       | `P&`                                                                      | Ensures: `t == nullptr`     |
-| `a != b`       | contextually convertible to `bool` | `!(a == b)`                 |
-| `a == np`      | contextually convertible to `bool` | `a == P()`                  |
 | `np == a`      |                                                                           |                             |
-| `a != np`      | contextually convertible to `bool` | `!(a == np)`                |
 | `np != a`      |                                                                           |                             |
 #### *Cpp17Hash* requirements <a id="hash.requirements">[[hash.requirements]]</a>
@@ -422,110 +510,480 @@ A type `H` meets the requirements if:
   and *Cpp17Destructible* ([[cpp17.destructible]]) requirements, and
 - the expressions shown in [[cpp17.hash]] are valid and have the
   indicated semantics.
 Given `Key` is an argument type for function objects of type `H`, in
-[[cpp17.hash]] `h` is a value of type (possibly `const`) `H`, `u` is an
 lvalue of type `Key`, and `k` is a value of a type convertible to
-(possibly `const`) `Key`.
 [*Note 1*: Thus all evaluations of the expression `h(k)` with the same
 value for `k` yield the same result for a given execution of the
 program. — *end note*]
 #### *Cpp17Allocator* requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
 The library describes a standard set of requirements for *allocators*,
 which are class-type objects that encapsulate the information about an
 allocation model. This information includes the knowledge of pointer
 types, the type of their difference, the type of the size of objects in
 this allocation model, as well as the memory allocation and deallocation
 primitives for it. All of the string types [[strings]], containers
 [[containers]] (except `array`), string buffers and string streams
 [[input.output]], and `match_results` [[re]] are parameterized in terms
 of allocators.
 The class template `allocator_traits` [[allocator.traits]] supplies a
-uniform interface to all allocator types. [[allocator.req.var]]
-describes the types manipulated through allocators. [[cpp17.allocator]]
-describes the requirements on allocator types and thus on types used to
-instantiate `allocator_traits`. A requirement is optional if the last
-column of [[cpp17.allocator]] specifies a default for a given
-expression. Within the standard library `allocator_traits` template, an
-optional requirement that is not supplied by an allocator is replaced by
-the specified default expression. A user specialization of
-`allocator_traits` may provide different defaults and may provide
-defaults for different requirements than the primary template. Within
-Tables  [[tab:allocator.req.var]] and  [[tab:cpp17.allocator]], the use
-of `move` and `forward` always refers to `std::move` and `std::forward`,
-respectively.
-[*Note 1*: If `n == 0`, the return value is unspecified. — *end note*]
-Note A: The member class template `rebind` in the table above is
-effectively a typedef template.
-[*Note 2*: In general, if the name `Allocator` is bound to
-`SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the same type
-as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is `T` and
-`SomeAllocator<U>::{}value_type` is `U`. — *end note*]
-If `Allocator` is a class template instantiation of the form
 `SomeAllocator<T, Args>`, where `Args` is zero or more type arguments,
 and `Allocator` does not supply a `rebind` member template, the standard
 `allocator_traits` template uses `SomeAllocator<U, Args>` in place of
-`Allocator::{}rebind<U>::other` by default. For allocator types that are
 not template instantiations of the above form, no default is provided.
-Note B: If `X::propagate_on_container_copy_assignment::value` is `true`,
-`X` shall meet the *Cpp17CopyAssignable* requirements (
-[[cpp17.copyassignable]]) and the copy operation shall not throw
-exceptions. If `X::propagate_on_container_move_assignment::value` is
-`true`, `X` shall meet the *Cpp17MoveAssignable* requirements (
-[[cpp17.moveassignable]]) and the move operation shall not throw
-exceptions. If `X::propagate_on_container_swap::value` is `true`,
-lvalues of type `X` shall be swappable [[swappable.requirements]] and
-the `swap` operation shall not throw exceptions.
 An allocator type `X` shall meet the *Cpp17CopyConstructible*
-requirements ([[cpp17.copyconstructible]]). The `X::pointer`,
-`X::const_pointer`, `X::void_pointer`, and `X::const_void_pointer` types
-shall meet the *Cpp17NullablePointer* requirements (
-[[cpp17.nullablepointer]]). No constructor, comparison function, copy
-operation, move operation, or swap operation on these pointer types
-shall exit via an exception. `X::pointer` and `X::const_pointer` shall
-also meet the requirements for a *Cpp17RandomAccessIterator*
-[[random.access.iterators]] and the additional requirement that, when
-`a` and `(a + n)` are dereferenceable pointer values for some integral
-value `n`,
 ``` cpp
-addressof(*(a + n)) == addressof(*a) + n
 ```
 is `true`.
 Let `x1` and `x2` denote objects of (possibly different) types
-`X::void_pointer`, `X::const_void_pointer`, `X::pointer`, or
-`X::const_pointer`. Then, `x1` and `x2` are *equivalently-valued*
 pointer values, if and only if both `x1` and `x2` can be explicitly
 converted to the two corresponding objects `px1` and `px2` of type
-`X::const_pointer`, using a sequence of `static_cast`s using only these
 four types, and the expression `px1 == px2` evaluates to `true`.
-Let `w1` and `w2` denote objects of type `X::void_pointer`. Then for the
-expressions
 ``` cpp
 w1 == w2
 w1 != w2
 ```
 either or both objects may be replaced by an equivalently-valued object
-of type `X::const_void_pointer` with no change in semantics.
-Let `p1` and `p2` denote objects of type `X::pointer`. Then for the
 expressions
 ``` cpp
 p1 == p2
 p1 != p2
@@ -535,11 +993,11 @@ p1 >= p2
 p1 > p2
 p1 - p2
 ```
 either or both objects may be replaced by an equivalently-valued object
-of type `X::const_pointer` with no change in semantics.
 An allocator may constrain the types on which it can be instantiated and
 the arguments for which its `construct` or `destroy` members may be
 called. If a type cannot be used with a particular allocator, the
 allocator class or the call to `construct` or `destroy` may fail to
@@ -548,34 +1006,32 @@ instantiate.
 If the alignment associated with a specific over-aligned type is not
 supported by an allocator, instantiation of the allocator for that type
 may fail. The allocator also may silently ignore the requested
 alignment.
-[*Note 3*: Additionally, the member function `allocate` for that type
-may fail by throwing an object of type `bad_alloc`. — *end note*]
 [*Example 1*:
 The following is an allocator class template supporting the minimal
-interface that meets the requirements of [[cpp17.allocator]]:
 ``` cpp
-template<class Tp>
 struct SimpleAllocator {
- typedef Tp value_type;
   SimpleAllocator(ctor args);
-  template<class T> SimpleAllocator(const SimpleAllocator<T>& other);
- [[nodiscard]] Tp* allocate(std::size_t n);
-  void deallocate(Tp* p, std::size_t n);
 };
-template<class T, class U>
-bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
-template<class T, class U>
-bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
 ```
 — *end example*]
 ##### Allocator completeness requirements <a id="allocator.requirements.completeness">[[allocator.requirements.completeness]]</a>
@@ -618,10 +1074,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
@@ -640,41 +1100,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
@@ -684,18 +1133,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
@@ -711,10 +1162,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`,
@@ -724,10 +1178,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`,
@@ -736,23 +1191,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.
@@ -772,36 +1230,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
@@ -818,15 +1280,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&)
@@ -858,11 +1320,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>
@@ -898,31 +1360,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.
@@ -933,22 +1394,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
@@ -966,15 +1428,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`.
@@ -1011,11 +1468,11 @@ those other 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 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>
@@ -1032,11 +1489,11 @@ stated otherwise.
 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 [[support]]
 through [[thread]] and [[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
@@ -1071,11 +1528,11 @@ 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
 document 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*]
 #### Friend functions <a id="hidden.friends">[[hidden.friends]]</a>
@@ -1141,12 +1598,12 @@ 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 an
 object with static storage duration 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.
@@ -1190,11 +1647,14 @@ the 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>
@@ -1203,41 +1663,30 @@ 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
@@ -1260,25 +1709,29 @@ associated values. — *end example*]
 Objects of types defined in the C++ standard library may be moved from
 [[class.copy.ctor]]. Move operations may be explicitly specified or
 implicitly generated. Unless otherwise specified, such moved-from
 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
 [algorithms.requirements]: algorithms.md#algorithms.requirements
 [alloc.errors]: support.md#alloc.errors
-[allocator.req.var]: #allocator.req.var
 [allocator.requirements]: #allocator.requirements
 [allocator.requirements.completeness]: #allocator.requirements.completeness
-[allocator.traits]: utilities.md#allocator.traits
 [alt.headers]: #alt.headers
-[atomics]: atomics.md#atomics
-[atomics.alias]: atomics.md#atomics.alias
-[atomics.lockfree]: atomics.md#atomics.lockfree
 [bad.alloc]: support.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
@@ -1286,24 +1739,24 @@ objects shall be placed in a valid but unspecified state.
 [basic.lookup.qual]: basic.md#basic.lookup.qual
 [basic.lookup.unqual]: basic.md#basic.lookup.unqual
 [basic.scope.namespace]: basic.md#basic.scope.namespace
 [basic.start]: basic.md#basic.start
 [basic.stc.dynamic]: basic.md#basic.stc.dynamic
-[basic.stc.dynamic.safety]: basic.md#basic.stc.dynamic.safety
-[basic.types]: basic.md#basic.types
-[bit]: numerics.md#bit
 [bitmask.types]: #bitmask.types
 [byte.strings]: #byte.strings
 [c.annex.k.names]: #c.annex.k.names
 [character.seq]: #character.seq
 [class.copy.assign]: class.md#class.copy.assign
 [class.copy.ctor]: class.md#class.copy.ctor
 [class.dtor]: class.md#class.dtor
 [class.mem]: class.md#class.mem
-[class.mfct]: class.md#class.mfct
-[class.this]: class.md#class.this
 [class.virtual]: class.md#class.virtual
 [cmp]: support.md#cmp
 [compliance]: #compliance
 [concept.destructible]: concepts.md#concept.destructible
 [concept.invocable]: concepts.md#concept.invocable
 [concept.totallyordered]: concepts.md#concept.totallyordered
@@ -1319,52 +1772,48 @@ objects shall be placed in a valid but unspecified state.
 [containers]: containers.md#containers
 [contents]: #contents
 [conv]: expr.md#conv
 [conv.func]: expr.md#conv.func
 [conventions]: #conventions
 [cpp.include]: cpp.md#cpp.include
 [cpp.replace]: cpp.md#cpp.replace
-[cpp17.allocator]: #cpp17.allocator
 [cpp17.copyassignable]: #cpp17.copyassignable
 [cpp17.copyconstructible]: #cpp17.copyconstructible
 [cpp17.destructible]: #cpp17.destructible
 [cpp17.hash]: #cpp17.hash
 [cpp17.moveassignable]: #cpp17.moveassignable
 [cpp17.nullablepointer]: #cpp17.nullablepointer
-[cstdint]: support.md#cstdint
 [customization.point.object]: #customization.point.object
 [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
 [dcl.pre]: dcl.md#dcl.pre
-[definitions]: #definitions
 [depr]: future.md#depr
-[depr.c.headers]: future.md#depr.c.headers
 [derivation]: #derivation
 [derived.classes]: #derived.classes
 [description]: #description
 [diagnostics]: diagnostics.md#diagnostics
 [enumerated.types]: #enumerated.types
 [except]: except.md#except
-[except.spec]: except.md#except.spec
-[expos.only.func]: #expos.only.func
-[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
-[expr.spaceship]: expr.md#expr.spaceship
 [expr.unary.op]: expr.md#expr.unary.op
 [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
@@ -1373,16 +1822,15 @@ objects shall be placed in a valid but unspecified state.
 [headers.cpp.c]: #headers.cpp.c
 [headers.cpp.fs]: #headers.cpp.fs
 [hidden.friends]: #hidden.friends
 [input.output]: input.md#input.output
 [intro.compliance]: intro.md#intro.compliance
-[intro.defs]: intro.md#intro.defs
-[intro.execution]: basic.md#intro.execution
 [intro.multithread]: basic.md#intro.multithread
 [intro.refs]: intro.md#intro.refs
 [iterator.requirements]: iterators.md#iterator.requirements
 [iterators]: iterators.md#iterators
 [lex.name]: lex.md#lex.name
 [lex.name.special]: #lex.name.special
 [lex.phases]: lex.md#lex.phases
 [lex.separate]: lex.md#lex.separate
 [lib.types.movedfrom]: #lib.types.movedfrom
@@ -1391,12 +1839,14 @@ objects shall be placed in a valid but unspecified state.
 [library.categories]: #library.categories
 [library.general]: #library.general
 [locales]: localization.md#locales
 [localization]: localization.md#localization
 [macro.names]: #macro.names
 [member.functions]: #member.functions
-[meta]: utilities.md#meta
 [module.import]: module.md#module.import
 [multibyte.strings]: #multibyte.strings
 [namespace.constraints]: #namespace.constraints
 [namespace.def]: dcl.md#namespace.def
 [namespace.future]: #namespace.future
@@ -1409,44 +1859,49 @@ objects shall be placed in a valid but unspecified state.
 [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
 [ranges]: ranges.md#ranges
 [re]: re.md#re
 [reentrancy]: #reentrancy
 [replacement.functions]: #replacement.functions
 [requirements]: #requirements
 [res.on.arguments]: #res.on.arguments
 [res.on.data.races]: #res.on.data.races
 [res.on.exception.handling]: #res.on.exception.handling
-[res.on.expects]: #res.on.expects
 [res.on.functions]: #res.on.functions
 [res.on.headers]: #res.on.headers
 [res.on.macro.definitions]: #res.on.macro.definitions
 [res.on.objects]: #res.on.objects
-[res.on.pointer.storage]: #res.on.pointer.storage
 [res.on.requirements]: #res.on.requirements
 [reserved.names]: #reserved.names
-[specialized.addressof]: utilities.md#specialized.addressof
 [std.exceptions]: diagnostics.md#std.exceptions
 [stmt.return]: stmt.md#stmt.return
 [stream.types]: input.md#stream.types
 [strings]: strings.md#strings
 [structure]: #structure
 [structure.elements]: #structure.elements
 [structure.requirements]: #structure.requirements
 [structure.see.also]: #structure.see.also
 [structure.specifications]: #structure.specifications
 [structure.summary]: #structure.summary
 [support]: support.md#support
 [support.coroutine]: support.md#support.coroutine
 [support.dynamic]: support.md#support.dynamic
 [support.exception]: support.md#support.exception
 [support.initlist]: support.md#support.initlist
 [support.limits]: support.md#support.limits
@@ -1456,90 +1911,93 @@ objects shall be placed in a valid but unspecified state.
 [support.start.term]: support.md#support.start.term
 [support.types]: support.md#support.types
 [swappable.requirements]: #swappable.requirements
 [syserr]: diagnostics.md#syserr
 [syserr.errcode.overview]: diagnostics.md#syserr.errcode.overview
-[tab:allocator.req.var]: #tab:allocator.req.var
-[tab:cpp17.allocator]: #tab:cpp17.allocator
 [tab:cpp17.destructible]: #tab:cpp17.destructible
 [tab:cpp17.equalitycomparable]: #tab:cpp17.equalitycomparable
 [temp]: temp.md#temp
 [temp.concept]: temp.md#temp.concept
 [temp.constr.decl]: temp.md#temp.constr.decl
-[temp.constr.order]: temp.md#temp.constr.order
 [temp.deduct.call]: temp.md#temp.deduct.call
-[temp.func.order]: temp.md#temp.func.order
 [template.bitset]: utilities.md#template.bitset
 [terminate.handler]: support.md#terminate.handler
 [thread]: thread.md#thread
 [time]: time.md#time
 [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.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, elements that do not apply to a function are
     omitted. For example, if a function specifies no preconditions,
     there will be no *Preconditions:* element.
-[^5]: This simplifies the presentation of complexity requirements in
     some cases.
-[^6]: Examples from  [[utility.requirements]] include:
     *Cpp17EqualityComparable*, *Cpp17LessThanComparable*,
     *Cpp17CopyConstructible*. Examples from  [[iterator.requirements]]
     include: *Cpp17InputIterator*, *Cpp17ForwardIterator*.
-[^7]: Such as an integer type, with constant integer values
     [[basic.fundamental]].
-[^8]: declared in `<clocale>`.
 [^9]: Many of the objects manipulated by function signatures declared in
     `<cstring>` 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 NTBS that 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 [[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.
@@ -1561,48 +2019,33 @@ objects shall be placed in a valid but unspecified state.
 [^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 document.
-[^22]: Any library customization point must be prepared to work
-    adequately with any user-defined overload that meets the minimum
-    requirements of this document. Therefore an implementation may
-    elect, under the as-if rule [[intro.execution]], to provide any
-    customization point in the form of an instantiated function object
-    [[function.objects]] even though the customization point’s
-    specification is in the form of a function template. The template
-    parameters of each such function object and the function parameters
-    and return type of the object’s `operator()` must match those of the
-    corresponding customization point’s specification.
-[^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]: 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]].

 ## Library-wide requirements <a id="requirements">[[requirements]]</a>
+### General <a id="requirements.general">[[requirements.general]]</a>
+Subclause [[requirements]] specifies requirements that apply to the
+entire C++ standard library. [[support]] through [[thread]] and [[depr]]
+specify the requirements of individual entities within the library.
 Requirements specified in terms of interactions between threads do not
 apply to programs having only a single thread of execution.
+[[organization]] describes the library’s contents and organization,
+[[using]] describes how well-formed C++ programs gain access to library
+entities, [[utility.requirements]] describes constraints on types and
+functions used with the C++ standard library, [[constraints]] describes
+constraints on well-formed C++ programs, and [[conforming]] describes
+constraints on conforming implementations.
 ### Library contents and organization <a id="organization">[[organization]]</a>
+#### General <a id="organization.general">[[organization.general]]</a>
 [[contents]] describes the entities and macros defined in the C++
 standard library. [[headers]] lists the standard library headers and
 some constraints on those headers. [[compliance]] lists requirements for
 a freestanding implementation of the C++ standard library.
 macros described in the synopses of the C++ standard library headers
 [[headers]], unless otherwise specified.
 All library entities except `operator new` and `operator delete` are
 defined within the namespace `std` or namespaces nested within namespace
+`std`.[^12]
+It is unspecified whether names declared in a specific namespace are
+declared directly in that namespace or in an inline namespace inside
+that namespace.[^13]
+Whenever an unqualified name other than `swap`, `make_error_code`, or
+`make_error_condition` is used in the specification of a declaration `D`
+in [[support]] through [[thread]] or [[depr]], its meaning is
+established as-if by performing unqualified name lookup
+[[basic.lookup.unqual]] in the context of `D`.
+[*Note 1*: Argument-dependent lookup is not performed. — *end note*]
+Similarly, the meaning of a *qualified-id* is established as-if by
+performing qualified name lookup [[basic.lookup.qual]] in the context of
+`D`.
+[*Example 1*: The reference to `is_array_v` in the specification of
+`std::to_array` [[array.creation]] refers to
+`::std::is_array_v`. — *end example*]
+[*Note 2*: Operators in expressions [[over.match.oper]] are not so
+constrained; see [[global.functions]]. — *end note*]
+The meaning of the unqualified name `swap` is established in an overload
+resolution context for swappable values [[swappable.requirements]]. The
+meanings of the unqualified names `make_error_code` and
+`make_error_condition` are established as-if by performing
+argument-dependent lookup [[basic.lookup.argdep]].
 #### Headers <a id="headers">[[headers]]</a>
 Each element of the C++ standard library is declared or defined (as
 appropriate) in a *header*.[^14]
 The headers listed in [[headers.cpp]], or, for a freestanding
 implementation, the subset of such headers that are provided by the
 implementation, are collectively known as the
 *importable C++ library headers*.
+[*Note 1*: Importable C++ library headers can be imported
+[[module.import]]. — *end note*]
 [*Example 1*:
 ``` cpp
 import <vector>;                // imports the <vector> header unit
 in the C++ standard library.[^16]
 Identifiers that are keywords or operators in C++ shall not be defined
 as macros in C++ standard library headers.[^17]
+[[support.c.headers]], C standard library headers, describes the effects
+of using the `name.h` (C header) form in a C++ program.[^18]
 Annex K of the C standard describes a large number of functions, with
 associated types and macros, which “promote safer, more secure
 programming” than many of the traditional C library functions. The names
 of the functions have a suffix of `_s`; most of them provide the same
 [[c.annex.k.names]] lists the Annex K names that may be declared in some
 header. These names are also subject to the restrictions of
 [[macro.names]].
+#### Modules <a id="std.modules">[[std.modules]]</a>
+The C++ standard library provides the following *C++ library modules*.
+The named module `std` exports declarations in namespace `std` that are
+provided by the importable C++ library headers ([[headers.cpp]] or the
+subset provided by a freestanding implementation) and the C++ headers
+for C library facilities ([[headers.cpp.c]]). It additionally exports
+declarations in the global namespace for the storage allocation and
+deallocation functions that are provided by `<new>`.
+The named module `std.compat` exports the same declarations as the named
+module `std`, and additionally exports declarations in the global
+namespace corresponding to the declarations in namespace `std` that are
+provided by the C++ headers for C library facilities (
+[[headers.cpp.c]]), except the explicitly excluded declarations
+described in [[support.c.headers.other]].
+It is unspecified to which module a declaration in the standard library
+is attached.
+[*Note 1*: Implementations are required to ensure that mixing
+`#include` and `import` does not result in conflicting attachments
+[[basic.link]]. — *end note*]
+*Recommended practice:* Implementations should ensure such attachments
+do not preclude further evolution or decomposition of the standard
+library modules.
+A declaration in the standard library denotes the same entity regardless
+of whether it was made reachable through including a header, importing a
+header unit, or importing a C++ library module.
+*Recommended practice:* Implementations should avoid exporting any other
+declarations from the C++ library modules.
+[*Note 2*: Like all named modules, the C++ library modules do not make
+macros visible [[module.import]], such as `assert` [[cassert.syn]],
+`errno` [[cerrno.syn]], `offsetof` [[cstddef.syn]], and `va_arg`
+[[cstdarg.syn]]. — *end note*]
 #### Freestanding implementations <a id="compliance">[[compliance]]</a>
+Two kinds of implementations are defined: hosted and freestanding
 [[intro.compliance]]; the kind of the implementation is
 *implementation-defined*. For a hosted implementation, this document
 describes the set of available headers.
 A freestanding implementation has an *implementation-defined* set of
 [[headers.cpp.fs]].
 **Table: C++ headers for freestanding implementations** <a id="headers.cpp.fs">[headers.cpp.fs]</a>
 | Subclause              |                                  | Header                                           |
+| ---------------------- | -------------------------------- | ------------------------------------------------ |
+| [[support.types]]      | Common definitions               | `<cstddef>`                                      |
 | [[support.limits]]     | Implementation properties        | `<cfloat>`, `<climits>`, `<limits>`, `<version>` |
+| [[cstdint.syn]] | Integer types | `<cstdint>`                                      |
 | [[support.start.term]] | Start and termination            | `<cstdlib>`                                      |
 | [[support.dynamic]]    | Dynamic memory management        | `<new>`                                          |
 | [[support.rtti]]       | Type identification              | `<typeinfo>`                                     |
 | [[support.srcloc]]     | Source location                  | `<source_location>`                              |
 | [[support.exception]]  | Exception handling               | `<exception>`                                    |
 | [[support.initlist]]   | Initializer lists                | `<initializer_list>`                             |
 | [[cmp]]                | Comparisons                      | `<compare>`                                      |
 | [[support.coroutine]]  | Coroutines support               | `<coroutine>`                                    |
 | [[support.runtime]]    | Other runtime support            | `<cstdarg>`                                      |
 | [[concepts]]           | Concepts library                 | `<concepts>`                                     |
+| [[type.traits]] | Type traits | `<type_traits>`                                  |
 | [[bit]]                | Bit manipulation                 | `<bit>`                                          |
 | [[atomics]]            | Atomics                          | `<atomic>`                                       |
+| [[utility]]            | Utility components               | `<utility>`                                      |
+| [[tuple]]              | Tuples                           | `<tuple>`                                        |
+| [[memory]]             | Memory                           | `<memory>`                                       |
+| [[function.objects]]   | Function objects                 | `<functional>`                                   |
+| [[ratio]]              | Compile-time rational arithmetic | `<ratio>`                                        |
+| [[iterators]]          | Iterators library                | `<iterator>`                                     |
+| [[ranges]]             | Ranges library                   | `<ranges>`                                       |
+For each of the headers listed in [[headers.cpp.fs]], a freestanding
+implementation provides at least the freestanding items
+[[freestanding.item]] declared in the header.
 ### Using the library <a id="using">[[using]]</a>
 #### Overview <a id="using.overview">[[using.overview]]</a>
 See also replacement functions [[replacement.functions]], runtime
 changes [[handler.functions]].
 ### Requirements on types and expressions <a id="utility.requirements">[[utility.requirements]]</a>
+#### General <a id="utility.requirements.general">[[utility.requirements.general]]</a>
 [[utility.arg.requirements]] describes requirements on types and
 expressions used to instantiate templates defined in the C++ standard
 library. [[swappable.requirements]] describes the requirements on
 swappable types and swappable expressions.
 [[nullablepointer.requirements]] describes the requirements on
 #### Template argument requirements <a id="utility.arg.requirements">[[utility.arg.requirements]]</a>
 The template definitions in the C++ standard library refer to various
 named requirements whose details are set out in Tables
 [[tab:cpp17.equalitycomparable]]– [[tab:cpp17.destructible]]. In these
+tables,
+- `T` denotes an object or reference type to be supplied by a C++
+  program instantiating a template,
+- `a`, `b`, and `c` denote values of type (possibly const) `T`,
+- `s` and `t` denote modifiable lvalues of type `T`,
+- `u` denotes an identifier,
+- `rv` denotes an rvalue of type `T`, and
+- `v` denotes an lvalue of type (possibly const) `T` or an rvalue of
+  type `const T`.
 In general, a default constructor is not required. Certain container
 class member function signatures specify `T()` as a default argument.
 `T()` shall be a well-defined expression [[dcl.init]] if one of those
 signatures is called using the default argument [[dcl.fct.default]].
 **Table: Cpp17EqualityComparable requirements** <a id="cpp17.equalitycomparable">[cpp17.equalitycomparable]</a>
 | Expression | Return type |
 | ---------- | ----------- |
+| `a == b`   | `decltype(a == b)` models `boolean-testable` | `==` is an equivalence relation, that is, it has the following properties: For all `a`, `a == a`.; If `a == b`, then `b == a`.; If `a == b` and `b == c`, then `a == c`. |
 **Table: Cpp17LessThanComparable requirements** <a id="cpp17.lessthancomparable">[cpp17.lessthancomparable]</a>
 | Expression | Return type                                 | Requirement                                            |
+| ---------- | ------------------------------------------- | ------------------------------------------------------ |
+| `a < b`    | `decltype(a < b)` models `boolean-testable` | `<` is a strict weak ordering relation [[alg.sorting]] |
 **Table: Cpp17DefaultConstructible requirements** <a id="cpp17.defaultconstructible">[cpp17.defaultconstructible]</a>
 | Expression     | Post-condition                                                      |
 | `T t;`         | object `t` is default-initialized                                   |
 | `T u{};`       | object `u` is value-initialized or aggregate-initialized            |
 | `T()`<br>`T{}` | an object of type `T` is value-initialized or aggregate-initialized |
+**Table: Cpp17MoveConstructible requirements** <a id="cpp17.moveconstructible">[cpp17.moveconstructible]</a>
+| Expression  | Post-condition                                                     |
+| ----------- | ------------------------------------------------------------------ |
+| `T u = rv;` | `u` is equivalent to the value of `rv` before the construction     |
+| `T(rv)`     | `T(rv)` is equivalent to the value of `rv` before the construction |
+| *[spans 2 columns]*  `rv`'s state is unspecified *`rv` must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether `rv` has been moved from or not.* |
 **Table: Cpp17CopyConstructible requirements (in addition to Cpp17MoveConstructible)** <a id="cpp17.copyconstructible">[cpp17.copyconstructible]</a>
 | Expression | Post-condition                                            |
 | ---------- | --------------------------------------------------------- |
 | `T u = v;` | the value of `v` is unchanged and is equivalent to ` u`   |
 | `T(v)`     | the value of `v` is unchanged and is equivalent to `T(v)` |
+**Table: Cpp17MoveAssignable requirements** <a id="cpp17.moveassignable">[cpp17.moveassignable]</a>
+| Expression | Return type | Return value | Post-condition                                                                                                |
+| ---------- | ----------- | ------------ | ------------------------------------------------------------------------------------------------------------- |
+| `t = rv`   | `T&`        | `t`          | If `t` and `rv` do not refer to the same object, `t` is equivalent to the value of `rv` before the assignment |
+| *[spans 4 columns]*  `rv`'s state is unspecified. *`rv` must still meet the requirements of the library component that is using it, whether or not `t` and `rv` refer to the same object. The operations listed in those requirements must work as specified whether `rv` has been moved from or not.* |
 **Table: Cpp17CopyAssignable requirements (in addition to Cpp17MoveAssignable)** <a id="cpp17.copyassignable">[cpp17.copyassignable]</a>
 | Expression | Return type | Return value | Post-condition                                          |
 | ---------- | ----------- | ------------ | ------------------------------------------------------- |
 | `t = v`    | `T&`        | `t`          | `t` is equivalent to `v`, the value of `v` is unchanged |
+**Table: Cpp17Destructible requirements** <a id="cpp17.destructible">[cpp17.destructible]</a>
+| Expression | Post-condition                                                        |
+| ---------- | --------------------------------------------------------------------- |
+| `u.~T()`   | All resources owned by `u` are reclaimed, no exception is propagated. |
+| *[spans 2 columns]*  *Array types and non-object types are not Cpp17Destructible.* |
 #### Swappable requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
 This subclause provides definitions for swappable types and expressions.
 In these definitions, let `t` denote an expression of type `T`, and let
 appropriate evaluation context. — *end note*]
 An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
 with any rvalue or lvalue, respectively, of type `T`.
+A type `X` meets the *Cpp17Swappable* requirements if lvalues of type
+`X` are swappable.
 A type `X` meeting any of the iterator requirements
 [[iterator.requirements]] meets the *Cpp17ValueSwappable* requirements
 if, for any dereferenceable object `x` of type `X`, `*x` is swappable.
 [*Example 1*:
 User code can ensure that the evaluation of `swap` calls is performed in
 an appropriate context under the various conditions as follows:
 ``` cpp
+#include <cassert>
 #include <utility>
+// Preconditions: std::forward<T>(t) is swappable with std::forward<U>(u).
 template<class T, class U>
 void value_swap(T&& t, U&& u) {
   using std::swap;
+  swap(std::forward<T>(t), std::forward<U>(u)); // OK, uses ``swappable with'' conditions
                                                 // for rvalues and lvalues
 }
+// Preconditions: T meets the Cpp17Swappable requirements.
 template<class T>
 void lv_swap(T& t1, T& t2) {
   using std::swap;
+  swap(t1, t2);                                 // OK, uses swappable conditions for lvalues of type T
 }
 namespace N {
   struct A { int m; };
   struct Proxy { A* a; };
   Proxy proxy(A& a) { return Proxy{ &a }; }
   void swap(A& x, Proxy p) {
+    std::swap(x.m, p.a->m);                     // OK, uses context equivalent to swappable
                                                 // conditions for fundamental types
   }
   void swap(Proxy p, A& x) { swap(x, p); }      // satisfy symmetry constraint
 }
 A *Cpp17NullablePointer* type is a pointer-like type that supports null
 values. A type `P` meets the *Cpp17NullablePointer* requirements if:
 - `P` meets the *Cpp17EqualityComparable*, *Cpp17DefaultConstructible*,
+  *Cpp17CopyConstructible*, *Cpp17CopyAssignable*, *Cpp17Swappable*, and
   *Cpp17Destructible* requirements,
 - the expressions shown in [[cpp17.nullablepointer]] are valid and have
   the indicated semantics, and
 - `P` meets all the other requirements of this subclause.
 A value-initialized object of type `P` produces the null value of the
 type. The null value shall be equivalent only to itself. A
 default-initialized object of type `P` may have an indeterminate value.
+[*Note 1*: Operations involving indeterminate values can cause
 undefined behavior. — *end note*]
 An object `p` of type `P` can be contextually converted to `bool`
 [[conv]]. The effect shall be as if `p != nullptr` had been evaluated in
 place of `p`.
 No operation which is part of the *Cpp17NullablePointer* requirements
 shall exit via an exception.
 In [[cpp17.nullablepointer]], `u` denotes an identifier, `t` denotes a
 non-`const` lvalue of type `P`, `a` and `b` denote values of type
+(possibly const) `P`, and `np` denotes a value of type (possibly const)
+`std::nullptr_t`.
 **Table: Cpp17NullablePointer requirements** <a id="cpp17.nullablepointer">[cpp17.nullablepointer]</a>
 | Expression     | Return type                                                               | Operational semantics       |
+| -------------- | ------------------------------------------------------------------------- | --------------------------- |
 | `P u(np);`<br> |                                                                           | Ensures: `u == nullptr`     |
 | `P u = np;`    |                                                                           |                             |
 | `P(np)`        |                                                                           | Ensures: `P(np) == nullptr` |
 | `t = np`       | `P&`                                                                      | Ensures: `t == nullptr`     |
+| `a != b`       | `decltype(a != b)` models `boolean-testable` | `!(a == b)`                 |
+| `a == np`      | `decltype(a == np)` and `decltype(np == a)` each model `boolean-testable` | `a == P()`                  |
 | `np == a`      |                                                                           |                             |
+| `a != np`      | `decltype(a != np)` and `decltype(np != a)` each model `boolean-testable` | `!(a == np)`                |
 | `np != a`      |                                                                           |                             |
 #### *Cpp17Hash* requirements <a id="hash.requirements">[[hash.requirements]]</a>
   and *Cpp17Destructible* ([[cpp17.destructible]]) requirements, and
 - the expressions shown in [[cpp17.hash]] are valid and have the
   indicated semantics.
 Given `Key` is an argument type for function objects of type `H`, in
+[[cpp17.hash]] `h` is a value of type (possibly const) `H`, `u` is an
 lvalue of type `Key`, and `k` is a value of a type convertible to
+(possibly const) `Key`.
 [*Note 1*: Thus all evaluations of the expression `h(k)` with the same
 value for `k` yield the same result for a given execution of the
 program. — *end note*]
 #### *Cpp17Allocator* requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
+##### General <a id="allocator.requirements.general">[[allocator.requirements.general]]</a>
 The library describes a standard set of requirements for *allocators*,
 which are class-type objects that encapsulate the information about an
 allocation model. This information includes the knowledge of pointer
 types, the type of their difference, the type of the size of objects in
 this allocation model, as well as the memory allocation and deallocation
 primitives for it. All of the string types [[strings]], containers
 [[containers]] (except `array`), string buffers and string streams
 [[input.output]], and `match_results` [[re]] are parameterized in terms
 of allocators.
+In subclause [[allocator.requirements]],
+- `T`, `U`, `C` denote any cv-unqualified object type
+  [[term.object.type]],
+- `X` denotes an allocator class for type `T`,
+- `Y` denotes the corresponding allocator class for type `U`,
+- `XX` denotes the type `allocator_traits<X>`,
+- `YY` denotes the type `allocator_traits<Y>`,
+- `a`, `a1`, `a2` denote lvalues of type `X`,
+- `u` denotes the name of a variable being declared,
+- `b` denotes a value of type `Y`,
+- `c` denotes a pointer of type `C*` through which indirection is valid,
+- `p` denotes a value of type `XX::pointer` obtained by calling
+  `a1.allocate`, where `a1 == a`,
+- `q` denotes a value of type `XX::const_pointer` obtained by conversion
+  from a value `p`,
+- `r` denotes a value of type `T&` obtained by the expression `*p`,
+- `w` denotes a value of type `XX::void_pointer` obtained by conversion
+  from a value `p`,
+- `x` denotes a value of type `XX::const_void_pointer` obtained by
+  conversion from a value `q` or a value `w`,
+- `y` denotes a value of type `XX::const_void_pointer` obtained by
+  conversion from a result value of `YY::allocate`, or else a value of
+  type (possibly const) `std::nullptr_t`,
+- `n` denotes a value of type `XX::size_type`,
+- `Args` denotes a template parameter pack, and
+- `args` denotes a function parameter pack with the pattern `Args&&`.
 The class template `allocator_traits` [[allocator.traits]] supplies a
+uniform interface to all allocator types. This subclause describes the
+requirements on allocator types and thus on types used to instantiate
+`allocator_traits`. A requirement is optional if a default for a given
+type or expression is specified. Within the standard library
+`allocator_traits` template, an optional requirement that is not
+supplied by an allocator is replaced by the specified default type or
+expression.
+[*Note 1*: There are no program-defined specializations of
+`allocator_traits`. — *end note*]
+``` cpp
+typename X::pointer
+```
+*Remarks:* Default: `T*`
+``` cpp
+typename X::const_pointer
+```
+*Mandates:* `XX::pointer` is convertible to `XX::const_pointer`.
+*Remarks:* Default: `pointer_traits<XX::pointer>::rebind<const T>`
+``` cpp
+typename X::void_pointer
+typename Y::void_pointer
+```
+*Mandates:* `XX::pointer` is convertible to `XX::void_pointer`.
+`XX::void_pointer` and `YY::void_pointer` are the same type.
+*Remarks:* Default: `pointer_traits<XX::pointer>::rebind<void>`
+``` cpp
+typename X::const_void_pointer
+typename Y::const_void_pointer
+```
+*Mandates:* `XX::pointer`, `XX::const_pointer`, and `XX::void_pointer`
+are convertible to `XX::const_void_pointer`. `XX::const_void_pointer`
+and `YY::const_void_pointer` are the same type.
+*Remarks:* Default: `pointer_traits<XX::pointer>::rebind<const void>`
+``` cpp
+typename X::value_type
+```
+*Result:* Identical to `T`.
+``` cpp
+typename X::size_type
+```
+*Result:* An unsigned integer type that can represent the size of the
+largest object in the allocation model.
+*Remarks:* Default: `make_unsigned_t<XX::difference_type>`
+``` cpp
+typename X::difference_type
+```
+*Result:* A signed integer type that can represent the difference
+between any two pointers in the allocation model.
+*Remarks:* Default: `pointer_traits<XX::pointer>::difference_type`
+``` cpp
+typename X::template rebind<U>::other
+```
+*Result:* `Y`
+*Ensures:* For all `U` (including `T`), `YY::rebind_alloc<T>` is `X`.
+*Remarks:* If `Allocator` is a class template instantiation of the form
 `SomeAllocator<T, Args>`, where `Args` is zero or more type arguments,
 and `Allocator` does not supply a `rebind` member template, the standard
 `allocator_traits` template uses `SomeAllocator<U, Args>` in place of
+`Allocator::rebind<U>::other` by default. For allocator types that are
 not template instantiations of the above form, no default is provided.
+[*Note 1*: The member class template `rebind` of `X` is effectively a
+typedef template. In general, if the name `Allocator` is bound to
+`SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the same type
+as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is `T` and
+`SomeAllocator<U>::value_type` is `U`. — *end note*]
+``` cpp
+*p
+```
+*Result:* `T&`
+``` cpp
+*q
+```
+*Result:* `const T&`
+*Ensures:* `*q` refers to the same object as `*p`.
+``` cpp
+p->m
+```
+*Result:* Type of `T::m`.
+*Preconditions:* `(*p).m` is well-defined.
+*Effects:* Equivalent to `(*p).m`.
+``` cpp
+q->m
+```
+*Result:* Type of `T::m`.
+*Preconditions:* `(*q).m` is well-defined.
+*Effects:* Equivalent to `(*q).m`.
+``` cpp
+static_cast<XX::pointer>(w)
+```
+*Result:* `XX::pointer`
+*Ensures:* `static_cast<XX::pointer>(w) == p`.
+``` cpp
+static_cast<XX::const_pointer>(x)
+```
+*Result:* `XX::const_pointer`
+*Ensures:* `static_cast<XX::const_pointer>(x) == q`.
+``` cpp
+pointer_traits<XX::pointer>::pointer_to(r)
+```
+*Result:* `XX::pointer`
+*Ensures:* Same as `p`.
+``` cpp
+a.allocate(n)
+```
+*Result:* `XX::pointer`
+*Effects:* Memory is allocated for an array of `n` `T` and such an
+object is created but array elements are not constructed.
+[*Example 1*: When reusing storage denoted by some pointer value `p`,
+`launder(reinterpret_cast<T*>(new (p) byte[n * sizeof(T)]))` can be used
+to implicitly create a suitable array object and obtain a pointer to
+it. — *end example*]
+*Throws:* `allocate` may throw an appropriate exception.
+[*Note 2*: It is intended that `a.allocate` be an efficient means of
+allocating a single object of type `T`, even when `sizeof(T)` is small.
+That is, there is no need for a container to maintain its own free
+list. — *end note*]
+*Remarks:* If `n == 0`, the return value is unspecified.
+``` cpp
+a.allocate(n, y)
+```
+*Result:* `XX::pointer`
+*Effects:* Same as `a.allocate(n)`. The use of `y` is unspecified, but
+it is intended as an aid to locality.
+*Remarks:* Default: `a.allocate(n)`
+``` cpp
+a.allocate_at_least(n)
+```
+*Result:* `allocation_result<XX::pointer, XX::size_type>`
+*Returns:* `allocation_result<XX::pointer, XX::size_type>{ptr, count}`
+where `ptr` is memory allocated for an array of `count` `T` and such an
+object is created but array elements are not constructed, such that
+`count` ≥ `n`. If `n == 0`, the return value is unspecified.
+*Throws:* `allocate_at_least` may throw an appropriate exception.
+*Remarks:* Default: `{a.allocate(n), n}`.
+``` cpp
+a.deallocate(p, n)
+```
+*Result:* (not used)
+*Preconditions:*
+- If `p` is memory that was obtained by a call to `a.allocate_at_least`,
+  let `ret` be the value returned and `req` be the value passed as the
+  first argument of that call. `p` is equal to `ret.ptr` and `n` is a
+  value such that `req` ≤ `n` ≤ `ret.count`.
+- Otherwise, `p` is a pointer value obtained from `allocate`. `n` equals
+  the value passed as the first argument to the invocation of `allocate`
+  which returned `p`.
+`p` has not been invalidated by an intervening call to `deallocate`.
+*Throws:* Nothing.
+``` cpp
+a.max_size()
+```
+*Result:* `XX::size_type`
+*Returns:* The largest value `n` that can meaningfully be passed to
+`a.allocate(n)`.
+*Remarks:* Default:
+`numeric_limits<size_type>::max() / sizeof(value_type)`
+``` cpp
+a1 == a2
+```
+*Result:* `bool`
+*Returns:* `true` only if storage allocated from each can be deallocated
+via the other.
+*Throws:* Nothing.
+*Remarks:* `operator==` shall be reflexive, symmetric, and transitive.
+``` cpp
+a1 != a2
+```
+*Result:* `bool`
+*Returns:* `!(a1 == a2)`.
+``` cpp
+a == b
+```
+*Result:* `bool`
+*Returns:* `a == YY::rebind_alloc<T>(b)`.
+``` cpp
+a != b
+```
+*Result:* `bool`
+*Returns:* `!(a == b)`.
+``` cpp
+X u(a);
+X u = a;
+```
+*Ensures:* `u == a`
+*Throws:* Nothing.
+``` cpp
+X u(b);
+```
+*Ensures:* `Y(u) == b` and `u == X(b)`.
+*Throws:* Nothing.
+``` cpp
+X u(std::move(a));
+X u = std::move(a);
+```
+*Ensures:* The value of `a` is unchanged and is equal to `u`.
+*Throws:* Nothing.
+``` cpp
+X u(std::move(b));
+```
+*Ensures:* `u` is equal to the prior value of `X(b)`.
+*Throws:* Nothing.
+``` cpp
+a.construct(c, args)
+```
+*Result:* (not used)
+*Effects:* Constructs an object of type `C` at `c`.
+*Remarks:* Default: `construct_at(c, std::forward<Args>(args)...)`
+``` cpp
+a.destroy(c)
+```
+*Result:* (not used)
+*Effects:* Destroys the object at `c`.
+*Remarks:* Default: `destroy_at(c)`
+``` cpp
+a.select_on_container_copy_construction()
+```
+*Result:* `X`
+*Returns:* Typically returns either `a` or `X()`.
+*Remarks:* Default: `return a;`
+``` cpp
+typename X::propagate_on_container_copy_assignment
+```
+*Result:* Identical to or derived from `true_type` or `false_type`.
+*Returns:* `true_type` only if an allocator of type `X` should be copied
+when the client container is copy-assigned; if so, `X` shall meet the
+*Cpp17CopyAssignable* requirements ([[cpp17.copyassignable]]) and the
+copy operation shall not throw exceptions.
+*Remarks:* Default: `false_type`
+``` cpp
+typename X::propagate_on_container_move_assignment
+```
+*Result:* Identical to or derived from `true_type` or `false_type`.
+*Returns:* `true_type` only if an allocator of type `X` should be moved
+when the client container is move-assigned; if so, `X` shall meet the
+*Cpp17MoveAssignable* requirements ([[cpp17.moveassignable]]) and the
+move operation shall not throw exceptions.
+*Remarks:* Default: `false_type`
+``` cpp
+typename X::propagate_on_container_swap
+```
+*Result:* Identical to or derived from `true_type` or `false_type`.
+*Returns:* `true_type` only if an allocator of type `X` should be
+swapped when the client container is swapped; if so, `X` shall meet the
+*Cpp17Swappable* requirements [[swappable.requirements]] and the `swap`
+operation shall not throw exceptions.
+*Remarks:* Default: `false_type`
+``` cpp
+typename X::is_always_equal
+```
+*Result:* Identical to or derived from `true_type` or `false_type`.
+*Returns:* `true_type` only if the expression `a1 == a2` is guaranteed
+to be `true` for any two (possibly const) values `a1`, `a2` of type `X`.
+*Remarks:* Default: `is_empty<X>::type`
 An allocator type `X` shall meet the *Cpp17CopyConstructible*
+requirements ([[cpp17.copyconstructible]]). The `XX::pointer`,
+`XX::const_pointer`, `XX::void_pointer`, and `XX::const_void_pointer`
+types shall meet the *Cpp17NullablePointer* requirements (
+[[cpp17.nullablepointer]]). No constructor, comparison operator
+function, copy operation, move operation, or swap operation on these
+pointer types shall exit via an exception. `XX::pointer` and
+`XX::const_pointer` shall also meet the requirements for a
+*Cpp17RandomAccessIterator* [[random.access.iterators]] and the
+additional requirement that, when `p` and `(p + n)` are dereferenceable
+pointer values for some integral value `n`,
 ``` cpp
+addressof(*(p + n)) == addressof(*p) + n
 ```
 is `true`.
 Let `x1` and `x2` denote objects of (possibly different) types
+`XX::void_pointer`, `XX::const_void_pointer`, `XX::pointer`, or
+`XX::const_pointer`. Then, `x1` and `x2` are *equivalently-valued*
 pointer values, if and only if both `x1` and `x2` can be explicitly
 converted to the two corresponding objects `px1` and `px2` of type
+`XX::const_pointer`, using a sequence of `static_cast`s using only these
 four types, and the expression `px1 == px2` evaluates to `true`.
+Let `w1` and `w2` denote objects of type `XX::void_pointer`. Then for
+the expressions
 ``` cpp
 w1 == w2
 w1 != w2
 ```
 either or both objects may be replaced by an equivalently-valued object
+of type `XX::const_void_pointer` with no change in semantics.
+Let `p1` and `p2` denote objects of type `XX::pointer`. Then for the
 expressions
 ``` cpp
 p1 == p2
 p1 != p2
 p1 > p2
 p1 - p2
 ```
 either or both objects may be replaced by an equivalently-valued object
+of type `XX::const_pointer` with no change in semantics.
 An allocator may constrain the types on which it can be instantiated and
 the arguments for which its `construct` or `destroy` members may be
 called. If a type cannot be used with a particular allocator, the
 allocator class or the call to `construct` or `destroy` may fail to
 If the alignment associated with a specific over-aligned type is not
 supported by an allocator, instantiation of the allocator for that type
 may fail. The allocator also may silently ignore the requested
 alignment.
+[*Note 2*: Additionally, the member function `allocate` for that type
+can fail by throwing an object of type `bad_alloc`. — *end note*]
 [*Example 1*:
 The following is an allocator class template supporting the minimal
+interface that meets the requirements of
+[[allocator.requirements.general]]:
 ``` cpp
+template<class T>
 struct SimpleAllocator {
+ using value_type = T;
   SimpleAllocator(ctor args);
+  template<class U> SimpleAllocator(const SimpleAllocator<U>& other);
+ T* allocate(std::size_t n);
+  void deallocate(T* p, std::size_t n);
+  template<class U> bool operator==(const SimpleAllocator<U>& rhs) const;
 };
 ```
 — *end example*]
 ##### Allocator completeness requirements <a id="allocator.requirements.completeness">[[allocator.requirements.completeness]]</a>
 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`.
 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 [[support.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>
 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 [[support]]
 through [[thread]] and [[depr]] shall behave as if the implementation
+declared no additional non-member function signatures.[^25]
 An implementation shall not declare a non-member function signature with
 additional default arguments.
 Unless otherwise specified, calls made by functions in the standard
 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
 document behaves as if that overload were selected.
+[*Note 1*: For instance, an implementation can 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*]
 #### Friend functions <a id="hidden.friends">[[hidden.friends]]</a>
 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 an
 object with static storage duration for internal purposes without
+synchronization because doing so can 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.
 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. \[*Note 1*: There is an implicit exception to this
+  rule for types that are described as synonyms
+  [[dcl.typedef]], [[namespace.udecl]], such as `size_t`
+  [[support.types]] and `streamoff` [[stream.types]]. — *end note*]
 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>
 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 [^26]
 except when such a function calls a program-supplied function that
+throws an exception.[^27]
 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.[^28]
 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.
 #### 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
 Objects of types defined in the C++ standard library may be moved from
 [[class.copy.ctor]]. Move operations may be explicitly specified or
 implicitly generated. Unless otherwise specified, such moved-from
 objects shall be placed in a valid but unspecified state.
+An object of a type defined in the C++ standard library may be
+move-assigned [[class.copy.assign]] to itself. Unless otherwise
+specified, such an assignment places the object 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
 [algorithms.requirements]: algorithms.md#algorithms.requirements
 [alloc.errors]: support.md#alloc.errors
 [allocator.requirements]: #allocator.requirements
 [allocator.requirements.completeness]: #allocator.requirements.completeness
+[allocator.requirements.general]: #allocator.requirements.general
+[allocator.traits]: mem.md#allocator.traits
 [alt.headers]: #alt.headers
+[array.creation]: containers.md#array.creation
+[atomics]: thread.md#atomics
 [bad.alloc]: support.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.qual]: basic.md#basic.lookup.qual
 [basic.lookup.unqual]: basic.md#basic.lookup.unqual
 [basic.scope.namespace]: basic.md#basic.scope.namespace
 [basic.start]: basic.md#basic.start
 [basic.stc.dynamic]: basic.md#basic.stc.dynamic
+[bit]: utilities.md#bit
 [bitmask.types]: #bitmask.types
 [byte.strings]: #byte.strings
 [c.annex.k.names]: #c.annex.k.names
+[cassert.syn]: diagnostics.md#cassert.syn
+[cerrno.syn]: diagnostics.md#cerrno.syn
 [character.seq]: #character.seq
+[character.seq.general]: #character.seq.general
 [class.copy.assign]: class.md#class.copy.assign
 [class.copy.ctor]: class.md#class.copy.ctor
 [class.dtor]: class.md#class.dtor
 [class.mem]: class.md#class.mem
 [class.virtual]: class.md#class.virtual
+[clocale.syn]: localization.md#clocale.syn
 [cmp]: support.md#cmp
 [compliance]: #compliance
 [concept.destructible]: concepts.md#concept.destructible
 [concept.invocable]: concepts.md#concept.invocable
 [concept.totallyordered]: concepts.md#concept.totallyordered
 [containers]: containers.md#containers
 [contents]: #contents
 [conv]: expr.md#conv
 [conv.func]: expr.md#conv.func
 [conventions]: #conventions
+[conventions.general]: #conventions.general
 [cpp.include]: cpp.md#cpp.include
 [cpp.replace]: cpp.md#cpp.replace
 [cpp17.copyassignable]: #cpp17.copyassignable
 [cpp17.copyconstructible]: #cpp17.copyconstructible
 [cpp17.destructible]: #cpp17.destructible
 [cpp17.hash]: #cpp17.hash
 [cpp17.moveassignable]: #cpp17.moveassignable
 [cpp17.nullablepointer]: #cpp17.nullablepointer
+[cstdarg.syn]: support.md#cstdarg.syn
+[cstddef.syn]: support.md#cstddef.syn
+[cstdint.syn]: support.md#cstdint.syn
 [customization.point.object]: #customization.point.object
 [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.inline]: dcl.md#dcl.inline
 [dcl.link]: dcl.md#dcl.link
 [dcl.pre]: dcl.md#dcl.pre
+[dcl.typedef]: dcl.md#dcl.typedef
+[defns.nonconst.libcall]: intro.md#defns.nonconst.libcall
 [depr]: future.md#depr
 [derivation]: #derivation
 [derived.classes]: #derived.classes
 [description]: #description
+[description.general]: #description.general
 [diagnostics]: diagnostics.md#diagnostics
 [enumerated.types]: #enumerated.types
 [except]: except.md#except
+[expos.only.entity]: #expos.only.entity
 [expr.delete]: expr.md#expr.delete
 [expr.new]: expr.md#expr.new
 [expr.unary.op]: expr.md#expr.unary.op
 [extern.names]: #extern.names
 [extern.types]: #extern.types
+[freestanding.item]: #freestanding.item
 [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.cpp.c]: #headers.cpp.c
 [headers.cpp.fs]: #headers.cpp.fs
 [hidden.friends]: #hidden.friends
 [input.output]: input.md#input.output
 [intro.compliance]: intro.md#intro.compliance
 [intro.multithread]: basic.md#intro.multithread
 [intro.refs]: intro.md#intro.refs
 [iterator.requirements]: iterators.md#iterator.requirements
 [iterators]: iterators.md#iterators
+[lex.charset]: lex.md#lex.charset
 [lex.name]: lex.md#lex.name
 [lex.name.special]: #lex.name.special
 [lex.phases]: lex.md#lex.phases
 [lex.separate]: lex.md#lex.separate
 [lib.types.movedfrom]: #lib.types.movedfrom
 [library.categories]: #library.categories
 [library.general]: #library.general
 [locales]: localization.md#locales
 [localization]: localization.md#localization
 [macro.names]: #macro.names
+[mem]: mem.md#mem
 [member.functions]: #member.functions
+[memory]: mem.md#memory
+[meta]: meta.md#meta
 [module.import]: module.md#module.import
 [multibyte.strings]: #multibyte.strings
 [namespace.constraints]: #namespace.constraints
 [namespace.def]: dcl.md#namespace.def
 [namespace.future]: #namespace.future
 [nullablepointer.requirements]: #nullablepointer.requirements
 [numeric.requirements]: numerics.md#numeric.requirements
 [numerics]: numerics.md#numerics
 [objects.within.classes]: #objects.within.classes
 [organization]: #organization
+[organization.general]: #organization.general
 [ostream.iterator.ops]: iterators.md#ostream.iterator.ops
 [over.literal]: over.md#over.literal
 [over.match]: over.md#over.match
+[over.match.oper]: over.md#over.match.oper
 [protection.within.classes]: #protection.within.classes
 [random.access.iterators]: iterators.md#random.access.iterators
 [ranges]: ranges.md#ranges
+[ratio]: meta.md#ratio
 [re]: re.md#re
 [reentrancy]: #reentrancy
 [replacement.functions]: #replacement.functions
 [requirements]: #requirements
+[requirements.general]: #requirements.general
 [res.on.arguments]: #res.on.arguments
 [res.on.data.races]: #res.on.data.races
 [res.on.exception.handling]: #res.on.exception.handling
 [res.on.functions]: #res.on.functions
 [res.on.headers]: #res.on.headers
 [res.on.macro.definitions]: #res.on.macro.definitions
 [res.on.objects]: #res.on.objects
 [res.on.requirements]: #res.on.requirements
 [reserved.names]: #reserved.names
+[reserved.names.general]: #reserved.names.general
+[specialized.addressof]: mem.md#specialized.addressof
 [std.exceptions]: diagnostics.md#std.exceptions
+[std.modules]: #std.modules
 [stmt.return]: stmt.md#stmt.return
 [stream.types]: input.md#stream.types
 [strings]: strings.md#strings
 [structure]: #structure
 [structure.elements]: #structure.elements
 [structure.requirements]: #structure.requirements
 [structure.see.also]: #structure.see.also
 [structure.specifications]: #structure.specifications
 [structure.summary]: #structure.summary
 [support]: support.md#support
+[support.c.headers]: support.md#support.c.headers
+[support.c.headers.other]: support.md#support.c.headers.other
 [support.coroutine]: support.md#support.coroutine
 [support.dynamic]: support.md#support.dynamic
 [support.exception]: support.md#support.exception
 [support.initlist]: support.md#support.initlist
 [support.limits]: support.md#support.limits
 [support.start.term]: support.md#support.start.term
 [support.types]: support.md#support.types
 [swappable.requirements]: #swappable.requirements
 [syserr]: diagnostics.md#syserr
 [syserr.errcode.overview]: diagnostics.md#syserr.errcode.overview
 [tab:cpp17.destructible]: #tab:cpp17.destructible
 [tab:cpp17.equalitycomparable]: #tab:cpp17.equalitycomparable
 [temp]: temp.md#temp
 [temp.concept]: temp.md#temp.concept
 [temp.constr.decl]: temp.md#temp.constr.decl
 [temp.deduct.call]: temp.md#temp.deduct.call
 [template.bitset]: utilities.md#template.bitset
+[term.incomplete.type]: basic.md#term.incomplete.type
+[term.object.type]: basic.md#term.object.type
 [terminate.handler]: support.md#terminate.handler
 [thread]: thread.md#thread
 [time]: time.md#time
+[tuple]: utilities.md#tuple
 [type.descriptions]: #type.descriptions
 [type.descriptions.general]: #type.descriptions.general
+[type.traits]: meta.md#type.traits
 [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
+[utility.requirements.general]: #utility.requirements.general
 [value.error.codes]: #value.error.codes
 [zombie.names]: #zombie.names
+[^1]: See also ISO/IEC 9899:2018 section 7.6.
+[^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 operator
+ functions, there will be no “Comparison operator functions”
+    subclause.
+[^5]: To save space, elements that do not apply to a function are
     omitted. For example, if a function specifies no preconditions,
     there will be no *Preconditions:* element.
+[^6]: This simplifies the presentation of complexity requirements in
     some cases.
+[^7]: Examples from  [[utility.requirements]] include:
     *Cpp17EqualityComparable*, *Cpp17LessThanComparable*,
     *Cpp17CopyConstructible*. Examples from  [[iterator.requirements]]
     include: *Cpp17InputIterator*, *Cpp17ForwardIterator*.
+[^8]: Such as an integer type, with constant integer values
     [[basic.fundamental]].
 [^9]: Many of the objects manipulated by function signatures declared in
     `<cstring>` 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 NTBS that contains characters only from the basic literal
     character set is also an NTMBS. Each multibyte character then
     consists of a single byte.
+[^12]: The C standard library headers [[support.c.headers]] also define
     names within the global namespace, while the C++ headers for C
+    library facilities [[headers]] can 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: `<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.
 [^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 document.
+[^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]: A valid C++ program always calls the expected library non-member
+    function. An implementation can also define additional non-member
     functions that would otherwise not be called by a valid C++ program.
+[^26]: 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.
+[^27]: The functions `qsort()` and `bsearch()` [[alg.c.library]] meet
     this condition.
+[^28]: 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