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

Files changed (1) hide show

tmp/tmp1doj7uqu/{from.md → to.md} +220 -122

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

@@ -1,11 +1,11 @@
-## Method of description (Informative) <a id="description">[[description]]</a>
-This subclause describes the conventions used to specify the C++standard
-library. [[structure]] describes the structure of the normative Clauses
-[[language.support]] through  [[thread]] and Annex  [[depr]].
-[[conventions]] describes other editorial conventions.
 ### Structure of each clause <a id="structure">[[structure]]</a>
 #### Elements <a id="structure.elements">[[structure.elements]]</a>
@@ -21,59 +21,82 @@ Each library clause contains the following elements, as applicable:[^1]
 The Summary provides a synopsis of the category, and introduces the
 first-level subclauses. Each subclause also provides a summary, listing
 the headers specified in the subclause and the library entities provided
 in each header.
-Paragraphs labeled “Note(s):” or “Example(s):” are informative, other
-paragraphs are normative.
 The contents of the summary and the detailed specifications include:
 - macros
 - values
-- types
 - classes and class templates
 - functions and function templates
-- objects
 #### Requirements <a id="structure.requirements">[[structure.requirements]]</a>
-Requirements describe constraints that shall be met by a C++program that
-extends the standard library. Such extensions are generally one of the
-following:
 - Template arguments
 - Derived classes
 - Containers, iterators, and algorithms that meet an interface
-  convention
 The string and iostream components use an explicit representation of
 operations required of template arguments. They use a class template
 `char_traits` to define these constraints.
 Interface convention requirements are stated as generally as possible.
-Instead of stating “class X has to define a member function
 `operator++()`”, the interface requires “for any object `x` of class
 `X`, `++x` is defined”. That is, whether the operator is a member is
 unspecified.
 Requirements are stated in terms of well-defined expressions that define
-valid terms of the types that satisfy the requirements. For every set of
-well-defined expression requirements there is a table that specifies an
-initial set of the valid expressions and their semantics. Any generic
-algorithm (Clause  [[algorithms]]) that uses the well-defined expression
-requirements is described in terms of the valid expressions for its
-template type parameters.
 Template argument requirements are sometimes referenced by name. See
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++ code. Such
 code is intended as a specification of equivalence of a construct to
 another construct, not necessarily as the way the construct must be
 implemented.[^2]
 #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
 The detailed specifications each contain the following elements:
 - name and brief description
@@ -93,89 +116,138 @@ appropriate):[^3]
 - operators and other non-member functions
 Descriptions of function semantics contain the following elements (as
 appropriate):[^4]
-- *Requires:* the preconditions for calling the function
-- *Effects:* the actions performed by the function
-- *Synchronization:* the synchronization operations (
- [[intro.multithread]]) applicable to the function
-- *Postconditions:* the observable results established by the function
-- *Returns:* a description of the value(s) returned by the function
 - *Throws:* any exceptions thrown by the function, and the conditions
-  that would cause the exception
-- *Complexity:* the time and/or space complexity of the function
-- *Remarks:* additional semantic constraints on the function
 - *Error conditions:* the error conditions for error codes reported by
-  the function
-Whenever the *Effects:* element specifies that the semantics of some
 function `F` are *Equivalent to* some code sequence, then the various
-elements are interpreted as follows. If `F`’s semantics specifies a
-*Requires:* element, then that requirement is logically imposed prior to
-the *equivalent-to* semantics. Next, the semantics of the code sequence
-are determined by the *Requires:* , *Effects:* , *Synchronization:* ,
-*Postconditions:* , *Returns:* , *Throws:* , *Complexity:* , *Remarks:*
-, and *Error conditions:* specified for the function invocations
-contained in the code sequence. The value returned from `F` is specified
-by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
-non-`void` return from `F` is specified by the `return` statements in
-the code sequence. If `F`’s semantics contains a *Throws:* ,
-*Postconditions:* , or *Complexity:* element, then that supersedes any
 occurrences of that element in the code sequence.
-For non-reserved replacement and handler functions, Clause
-[[language.support]] specifies two behaviors for the functions in
-question: their required and default behavior. The *default behavior*
-describes a function definition provided by the implementation. The
-*required behavior* describes the semantics of a function definition
-provided by either the implementation or a C++program. Where no
-distinction is explicitly made in the description, the behavior
-described is the required behavior.
 If the formulation of a complexity requirement calls for a negative
 number of operations, the actual requirement is zero operations.[^5]
 Complexity requirements specified in the library clauses are upper
 bounds, and implementations that provide better complexity guarantees
-satisfy the requirements.
 Error conditions specify conditions where a function may fail. The
 conditions are listed, together with a suitable explanation, as the
-`enum class errc` constants ([[syserr]]).
 #### C library <a id="structure.see.also">[[structure.see.also]]</a>
-Paragraphs labeled “” contain cross-references to the relevant portions
-of this International Standard and the ISO C standard.
 ### Other conventions <a id="conventions">[[conventions]]</a>
 This subclause describes several editorial conventions used to describe
 the contents of the C++ standard library. These conventions are for
-describing implementation-defined types ([[type.descriptions]]), and
-member functions ([[functions.within.classes]]).
 #### Type descriptions <a id="type.descriptions">[[type.descriptions]]</a>
 ##### General <a id="type.descriptions.general">[[type.descriptions.general]]</a>
 The Requirements subclauses may describe names that are used to specify
 constraints on template arguments.[^6] These names are used in library
-Clauses to describe the types that may be supplied as arguments by a
-C++program when instantiating template components from the library.
-Certain types defined in Clause  [[input.output]] are used to describe
 implementation-defined types. They are based on other types, but with
 added constraints.
 ##### Exposition-only types <a id="expos.only.types">[[expos.only.types]]</a>
-Several types defined in Clauses  [[language.support]] through
-[[thread]] and Annex  [[depr]] that are used as function parameter or
-return types are defined for the purpose of exposition only in order to
-capture their language linkage. The declarations of such types are
 followed by a comment ending in *exposition only*.
 [*Example 1*:
 ``` cpp
@@ -189,73 +261,73 @@ function that takes a callback parameter with C language linkage.
 — *end example*]
 ##### Enumerated types <a id="enumerated.types">[[enumerated.types]]</a>
-Several types defined in Clause  [[input.output]] are *enumerated
-types*. Each enumerated type may be implemented as an enumeration or as
-a synonym for an enumeration.[^7]
 The enumerated type `enumerated` can be written:
 ``` cpp
-enum enumerated { V₀, V₁, V₂, V₃, ..... };
 inline const enumerated C₀(V₀);
 inline const enumerated C₁(V₁);
 inline const enumerated C₂(V₂);
 inline const enumerated C₃(V₃);
- .....
 ```
 Here, the names `C₀`, `C₁`, etc. represent *enumerated elements* for
 this particular enumerated type. All such elements have distinct values.
 ##### Bitmask types <a id="bitmask.types">[[bitmask.types]]</a>
-Several types defined in Clauses  [[language.support]] through
-[[thread]] and Annex  [[depr]] are *bitmask types*. Each bitmask type
-can be implemented as an enumerated type that overloads certain
-operators, as an integer type, or as a `bitset` ([[template.bitset]]).
-The bitmask type *bitmask* can be written:
 ``` cpp
 // For exposition only.
 // int_type is an integral type capable of representing all values of the bitmask type.
 enum bitmask : int_type {
-  V₀ = 1 << 0, V₁ = 1 << 1, V₂ = 1 << 2, V₃ = 1 << 3, .....
 };
 inline constexpr bitmask C₀(V₀{});
 inline constexpr bitmask C₁(V₁{});
 inline constexpr bitmask C₂(V₂{});
 inline constexpr bitmask C₃(V₃{});
- .....
-constexpr bitmask{} operator&(bitmask{} X, bitmask{} Y) {
-  return static_cast<bitmask{}>(
     static_cast<int_type>(X) & static_cast<int_type>(Y));
 }
-constexpr bitmask{} operator|(bitmask{} X, bitmask{} Y) {
-  return static_cast<bitmask{}>(
     static_cast<int_type>(X) | static_cast<int_type>(Y));
 }
-constexpr bitmask{} operator^(bitmask{} X, bitmask{} Y){
-  return static_cast<bitmask{}>(
     static_cast<int_type>(X) ^ static_cast<int_type>(Y));
 }
-constexpr bitmask{} operator~(bitmask{} X){
-  return static_cast<bitmask{}>(~static_cast<int_type>(X));
 }
-bitmask{}& operator&=(bitmask{}& X, bitmask{} Y){
   X = X & Y; return X;
 }
-bitmask{}& operator|=(bitmask{}& X, bitmask{} Y) {
   X = X | Y; return X;
 }
-bitmask{}& operator^=(bitmask{}& X, bitmask{} Y) {
   X = X ^ Y; return X;
 }
 ```
 Here, the names `C₀`, `C₁`, etc. represent *bitmask elements* for this
@@ -282,73 +354,99 @@ sequences that follow a few uniform conventions:
   basic execution character set.
 - The *decimal-point character* is the (single-byte) character used by
   functions that convert between a (single-byte) character sequence and
   a value of one of the floating-point types. It is used in the
   character sequence to denote the beginning of a fractional part. It is
-  represented in Clauses  [[language.support]] through  [[thread]] and
- Annex  [[depr]] by a period, `'.'`, which is also its value in the
- `"C"` locale, but may change during program execution by a call to
   `setlocale(int, const char*)`,[^8] or by a change to a `locale`
-  object, as described in Clauses  [[locales]] and  [[input.output]].
-- A *character sequence* is an array object ([[dcl.array]]) `A` that
- can be declared as `T A[N]`, where `T` is any of the types `char`,
-  `unsigned char`, or `signed char` ([[basic.fundamental]]), optionally
   qualified by any combination of `const` or `volatile`. The initial
   elements of the array have defined contents up to and including an
   element determined by some predicate. A character sequence can be
   designated by a pointer value `S` that points to its first element.
 ###### Byte strings <a id="byte.strings">[[byte.strings]]</a>
 A *null-terminated byte string*, or NTBS, is a character sequence whose
 highest-addressed element with defined content has the value zero (the
-*terminating null* character); no other element in the sequence has the
 value zero. [^9]
-The *length* of an NTBS is the number of elements that precede the
-terminating null character. An *empty* NTBS has a length of zero.
-The *value* of an NTBS is the sequence of values of the elements up to
 and including the terminating null character.
-A *static* NTBS is an NTBSwith static storage duration.[^10]
 ###### Multibyte strings <a id="multibyte.strings">[[multibyte.strings]]</a>
 A *null-terminated multibyte string*, or NTMBS, is an NTBS that
 constitutes a sequence of valid multibyte characters, beginning and
 ending in the initial shift state.[^11]
-A *static* NTMBS is an NTMBSwith static storage duration.
 #### Functions within classes <a id="functions.within.classes">[[functions.within.classes]]</a>
-For the sake of exposition, Clauses  [[language.support]] through
-[[thread]] and Annex  [[depr]] do not describe copy/move constructors,
-assignment operators, or (non-virtual) destructors with the same
-apparent semantics as those that can be generated by default (
-[[class.ctor]], [[class.dtor]], [[class.copy]]). It is unspecified
-whether the implementation provides explicit definitions for such member
-function signatures, or for virtual destructors that can be generated by
-default.
-For the sake of exposition, the library clauses sometimes annotate
-constructors with \EXPLICIT. Such a constructor is conditionally
-declared as either explicit or non-explicit ([[class.conv.ctor]]).
-[*Note 1*: This is typically implemented by declaring two such
-constructors, of which at most one participates in overload
-resolution. — *end note*]
 #### Private members <a id="objects.within.classes">[[objects.within.classes]]</a>
-Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]] do
-not specify the representation of classes, and intentionally omit
-specification of class members ([[class.mem]]). An implementation may
-define static or non-static class members, or both, as needed to
-implement the semantics of the member functions specified in Clauses
-[[language.support]] through  [[thread]] and Annex  [[depr]].
 For the sake of exposition, some subclauses provide representative
 declarations, and semantic requirements, for private members of classes
 that meet the external specifications of the classes. The declarations
 for such members are followed by a comment that ends with *exposition

+## Method of description <a id="description">[[description]]</a>
+This subclause describes the conventions used to specify the C++
+standard library. [[structure]] describes the structure of the normative
+[[support]] through [[thread]] and [[depr]]. [[conventions]] describes
+other editorial conventions.
 ### Structure of each clause <a id="structure">[[structure]]</a>
 #### Elements <a id="structure.elements">[[structure.elements]]</a>
 The Summary provides a synopsis of the category, and introduces the
 first-level subclauses. Each subclause also provides a summary, listing
 the headers specified in the subclause and the library entities provided
 in each header.
 The contents of the summary and the detailed specifications include:
 - macros
 - values
+- types and alias templates
 - classes and class templates
 - functions and function templates
+- objects and variable templates
+- concepts
 #### Requirements <a id="structure.requirements">[[structure.requirements]]</a>
+Requirements describe constraints that shall be met by a C++ program
+that extends the standard library. Such extensions are generally one of
+the following:
 - Template arguments
 - Derived classes
 - Containers, iterators, and algorithms that meet an interface
+  convention or model a concept
 The string and iostream components use an explicit representation of
 operations required of template arguments. They use a class template
 `char_traits` to define these constraints.
 Interface convention requirements are stated as generally as possible.
+Instead of stating “class `X` has to define a member function
 `operator++()`”, the interface requires “for any object `x` of class
 `X`, `++x` is defined”. That is, whether the operator is a member is
 unspecified.
 Requirements are stated in terms of well-defined expressions that define
+valid terms of the types that meet the requirements. For every set of
+well-defined expression requirements there is either a named concept or
+a table that specifies an initial set of the valid expressions and their
+semantics. Any generic algorithm [[algorithms]] that uses the
+well-defined expression requirements is described in terms of the valid
+expressions for its template type parameters.
+The library specification uses a typographical convention for naming
+requirements. Names in *italic* type that begin with the prefix *Cpp17*
+refer to sets of well-defined expression requirements typically
+presented in tabular form, possibly with additional prose semantic
+requirements. For example, *Cpp17Destructible* ([[cpp17.destructible]])
+is such a named requirement. Names in `constant width` type refer to
+library concepts which are presented as a concept definition [[temp]],
+possibly with additional prose semantic requirements. For example,
+`destructible` [[concept.destructible]] is such a named requirement.
 Template argument requirements are sometimes referenced by name. See
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++ code. Such
 code is intended as a specification of equivalence of a construct to
 another construct, not necessarily as the way the construct must be
 implemented.[^2]
+Required operations of any concept defined in this document need not be
+total functions; that is, some arguments to a required operation may
+result in the required semantics failing to be met.
+[*Example 1*: The required `<` operator of the `totally_ordered`
+concept [[concept.totallyordered]] does not meet the semantic
+requirements of that concept when operating on NaNs. — *end example*]
+This does not affect whether a type models the concept.
+A declaration may explicitly impose requirements through its associated
+constraints [[temp.constr.decl]]. When the associated constraints refer
+to a concept [[temp.concept]], the semantic constraints specified for
+that concept are additionally imposed on the use of the declaration.
 #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
 The detailed specifications each contain the following elements:
 - name and brief description
 - operators and other non-member functions
 Descriptions of function semantics contain the following elements (as
 appropriate):[^4]
+- *Constraints:* the conditions for the function’s participation in
+  overload resolution [[over.match]]. \[*Note 1*: Failure to meet such a
+  condition results in the function’s silent
+ non-viability. — *end note*] \[*Example 1*: An implementation might
+  express such a condition via a *constraint-expression*
+  [[temp.constr.decl]]. — *end example*]
+- *Mandates:* the conditions that, if not met, render the program
+  ill-formed. \[*Example 2*: An implementation might express such a
+  condition via the *constant-expression* in a
+  *static_assert-declaration* [[dcl.pre]]. If the diagnostic is to be
+  emitted only after the function has been selected by overload
+  resolution, an implementation might express such a condition via a
+  *constraint-expression* [[temp.constr.decl]] and also define the
+  function as deleted. — *end example*]
+- *Preconditions:* the conditions that the function assumes to hold
+  whenever it is called.
+- *Effects:* the actions performed by the function.
+- *Synchronization:* the synchronization operations
+  [[intro.multithread]] applicable to the function.
+- *Ensures:* the conditions (sometimes termed observable results)
+  established by the function.
+- *Returns:* a description of the value(s) returned by the function.
 - *Throws:* any exceptions thrown by the function, and the conditions
+  that would cause the exception.
+- *Complexity:* the time and/or space complexity of the function.
+- *Remarks:* additional semantic constraints on the function.
 - *Error conditions:* the error conditions for error codes reported by
+  the function.
+Whenever the *Effects* element specifies that the semantics of some
 function `F` are *Equivalent to* some code sequence, then the various
+elements are interpreted as follows. If `F`’s semantics specifies any
+*Constraints* or *Mandates* elements, then those requirements are
+logically imposed prior to the *equivalent-to* semantics. Next, the
+semantics of the code sequence are determined by the *Constraints*,
+*Mandates*, *Preconditions*, *Effects*, *Synchronization*,
+*Postconditions*, *Returns*, *Throws*, *Complexity*, *Remarks*, and
+*Error conditions* specified for the function invocations contained in
+the code sequence. The value returned from `F` is specified by `F`’s
+*Returns* element, or if `F` has no *Returns* element, a non-`void`
+return from `F` is specified by the `return` statements [[stmt.return]]
+in the code sequence. If `F`’s semantics contains a *Throws*,
+*Postconditions*, or *Complexity* element, then that supersedes any
 occurrences of that element in the code sequence.
+For non-reserved replacement and handler functions, [[support]]
+specifies two behaviors for the functions in question: their required
+and default behavior. The *default behavior* describes a function
+definition provided by the implementation. The *required behavior*
+describes the semantics of a function definition provided by either the
+implementation or a C++ program. Where no distinction is explicitly made
+in the description, the behavior described is the required behavior.
 If the formulation of a complexity requirement calls for a negative
 number of operations, the actual requirement is zero operations.[^5]
 Complexity requirements specified in the library clauses are upper
 bounds, and implementations that provide better complexity guarantees
+meet the requirements.
 Error conditions specify conditions where a function may fail. The
 conditions are listed, together with a suitable explanation, as the
+`enum class errc` constants [[syserr]].
 #### C library <a id="structure.see.also">[[structure.see.also]]</a>
+Paragraphs labeled “<span class="smallcaps">See also</span>” contain
+cross-references to the relevant portions of other standards
+[[intro.refs]].
 ### Other conventions <a id="conventions">[[conventions]]</a>
 This subclause describes several editorial conventions used to describe
 the contents of the C++ standard library. These conventions are for
+describing implementation-defined types [[type.descriptions]], and
+member functions [[functions.within.classes]].
+#### Exposition-only functions <a id="expos.only.func">[[expos.only.func]]</a>
+Several function templates defined in [[support]] through [[thread]] and
+[[depr]] are only defined for the purpose of exposition. The declaration
+of such a function is followed by a comment ending in *exposition only*.
+The following are defined for exposition only to aid in the
+specification of the library:
+``` cpp
+template<class T> constexpr decay_t<T> decay-copy(T&& v)
+    noexcept(is_nothrow_convertible_v<T, decay_t<T>>)           // exposition only
+  { return std::forward<T>(v); }
+constexpr auto synth-three-way =
+  []<class T, class U>(const T& t, const U& u)
+    requires requires {
+      { t < u } -> boolean-testable;
+      { u < t } -> boolean-testable;
+    }
+  {
+    if constexpr (three_way_comparable_with<T, U>) {
+      return t <=> u;
+    } else {
+      if (t < u) return weak_ordering::less;
+      if (u < t) return weak_ordering::greater;
+      return weak_ordering::equivalent;
+    }
+  };
+template<class T, class U=T>
+using synth-three-way-result = decltype(synth-three-way(declval<T&>(), declval<U&>()));
+```
 #### Type descriptions <a id="type.descriptions">[[type.descriptions]]</a>
 ##### General <a id="type.descriptions.general">[[type.descriptions.general]]</a>
 The Requirements subclauses may describe names that are used to specify
 constraints on template arguments.[^6] These names are used in library
+Clauses to describe the types that may be supplied as arguments by a C++
+program when instantiating template components from the library.
+Certain types defined in [[input.output]] are used to describe
 implementation-defined types. They are based on other types, but with
 added constraints.
 ##### Exposition-only types <a id="expos.only.types">[[expos.only.types]]</a>
+Several types defined in [[support]] through [[thread]] and [[depr]] are
+defined for the purpose of exposition. The declaration of such a type is
 followed by a comment ending in *exposition only*.
 [*Example 1*:
 ``` cpp
 — *end example*]
 ##### Enumerated types <a id="enumerated.types">[[enumerated.types]]</a>
+Several types defined in [[input.output]] are *enumerated types*. Each
+enumerated type may be implemented as an enumeration or as a synonym for
+an enumeration.[^7]
 The enumerated type `enumerated` can be written:
 ``` cpp
+enum enumerated { V₀, V₁, V₂, V₃, … };
 inline const enumerated C₀(V₀);
 inline const enumerated C₁(V₁);
 inline const enumerated C₂(V₂);
 inline const enumerated C₃(V₃);
+ ⋮
 ```
 Here, the names `C₀`, `C₁`, etc. represent *enumerated elements* for
 this particular enumerated type. All such elements have distinct values.
 ##### Bitmask types <a id="bitmask.types">[[bitmask.types]]</a>
+Several types defined in [[support]] through [[thread]] and [[depr]] are
+*bitmask types*. Each bitmask type can be implemented as an enumerated
+type that overloads certain operators, as an integer type, or as a
+`bitset` [[template.bitset]].
+The bitmask type `bitmask` can be written:
 ``` cpp
 // For exposition only.
 // int_type is an integral type capable of representing all values of the bitmask type.
 enum bitmask : int_type {
+  V₀ = 1 << 0, V₁ = 1 << 1, V₂ = 1 << 2, V₃ = 1 << 3, …
 };
 inline constexpr bitmask C₀(V₀{});
 inline constexpr bitmask C₁(V₁{});
 inline constexpr bitmask C₂(V₂{});
 inline constexpr bitmask C₃(V₃{});
+ ⋮
+constexpr bitmask operator&(bitmask X, bitmask Y) {
+  return static_cast<bitmask>(
     static_cast<int_type>(X) & static_cast<int_type>(Y));
 }
+constexpr bitmask operator|(bitmask X, bitmask Y) {
+  return static_cast<bitmask>(
     static_cast<int_type>(X) | static_cast<int_type>(Y));
 }
+constexpr bitmask operator^(bitmask X, bitmask Y){
+  return static_cast<bitmask>(
     static_cast<int_type>(X) ^ static_cast<int_type>(Y));
 }
+constexpr bitmask operator~(bitmask X){
+  return static_cast<bitmask>(~static_cast<int_type>(X));
 }
+bitmask& operator&=(bitmask& X, bitmask Y){
   X = X & Y; return X;
 }
+bitmask& operator|=(bitmask& X, bitmask Y) {
   X = X | Y; return X;
 }
+bitmask& operator^=(bitmask& X, bitmask Y) {
   X = X ^ Y; return X;
 }
 ```
 Here, the names `C₀`, `C₁`, etc. represent *bitmask elements* for this
   basic execution character set.
 - The *decimal-point character* is the (single-byte) character used by
   functions that convert between a (single-byte) character sequence and
   a value of one of the floating-point types. It is used in the
   character sequence to denote the beginning of a fractional part. It is
+  represented in [[support]] through [[thread]] and [[depr]] by a
+  period, `'.'`, which is also its value in the `"C"` locale, but may
+  change during program execution by a call to
   `setlocale(int, const char*)`,[^8] or by a change to a `locale`
+  object, as described in [[locales]] and [[input.output]].
+- A *character sequence* is an array object [[dcl.array]] `A` that can
+  be declared as `T A[N]`, where `T` is any of the types `char`,
+  `unsigned char`, or `signed char` [[basic.fundamental]], optionally
   qualified by any combination of `const` or `volatile`. The initial
   elements of the array have defined contents up to and including an
   element determined by some predicate. A character sequence can be
   designated by a pointer value `S` that points to its first element.
 ###### Byte strings <a id="byte.strings">[[byte.strings]]</a>
 A *null-terminated byte string*, or NTBS, is a character sequence whose
 highest-addressed element with defined content has the value zero (the
+*terminating null character*); no other element in the sequence has the
 value zero. [^9]
+The *length of an NTBS* is the number of elements that precede the
+terminating null character. An *empty NTBS* has a length of zero.
+The *value of an NTBS* is the sequence of values of the elements up to
 and including the terminating null character.
+A *static NTBS* is an NTBS with static storage duration.[^10]
 ###### Multibyte strings <a id="multibyte.strings">[[multibyte.strings]]</a>
 A *null-terminated multibyte string*, or NTMBS, is an NTBS that
 constitutes a sequence of valid multibyte characters, beginning and
 ending in the initial shift state.[^11]
+A *static NTMBS* is an NTMBS with static storage duration.
+##### Customization Point Object types <a id="customization.point.object">[[customization.point.object]]</a>
+A *customization point object* is a function object [[function.objects]]
+with a literal class type that interacts with program-defined types
+while enforcing semantic requirements on that interaction.
+The type of a customization point object, ignoring cv-qualifiers, shall
+model `semiregular` [[concepts.object]].
+All instances of a specific customization point object type shall be
+equal [[concepts.equality]].
+The type `T` of a customization point object shall model
+`invocable<const T&, Args...>` [[concept.invocable]] when the types in
+`Args...` meet the requirements specified in that customization point
+object’s definition. When the types of `Args...` do not meet the
+customization point object’s requirements, `T` shall not have a function
+call operator that participates in overload resolution.
+Each customization point object type constrains its return type to model
+a particular concept.
+[*Note 1*: Many of the customization point objects in the library
+evaluate function call expressions with an unqualified name which
+results in a call to a program-defined function found by argument
+dependent name lookup [[basic.lookup.argdep]]. To preclude such an
+expression resulting in a call to unconstrained functions with the same
+name in namespace `std`, customization point objects specify that lookup
+for these expressions is performed in a context that includes deleted
+overloads matching the signatures of overloads defined in namespace
+`std`. When the deleted overloads are viable, program-defined overloads
+need be more specialized [[temp.func.order]] or more constrained
+[[temp.constr.order]] to be used by a customization point
+object. — *end note*]
 #### Functions within classes <a id="functions.within.classes">[[functions.within.classes]]</a>
+For the sake of exposition, [[support]] through [[thread]] and [[depr]]
+do not describe copy/move constructors, assignment operators, or
+(non-virtual) destructors with the same apparent semantics as those that
+can be generated by default ([[class.copy.ctor]],
+[[class.copy.assign]], [[class.dtor]]). It is unspecified whether the
+implementation provides explicit definitions for such member function
+signatures, or for virtual destructors that can be generated by default.
 #### Private members <a id="objects.within.classes">[[objects.within.classes]]</a>
+[[support]] through [[thread]] and [[depr]] do not specify the
+representation of classes, and intentionally omit specification of class
+members [[class.mem]]. An implementation may define static or non-static
+class members, or both, as needed to implement the semantics of the
+member functions specified in [[support]] through [[thread]] and
+[[depr]].
 For the sake of exposition, some subclauses provide representative
 declarations, and semantic requirements, for private members of classes
 that meet the external specifications of the classes. The declarations
 for such members are followed by a comment that ends with *exposition

Diff to HTML by rtfpessoa