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

Files changed (1) hide show

tmp/tmpwpc9m21n/{from.md → to.md} +149 -78

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

@@ -1,17 +1,19 @@
 ## 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>
-Each library clause contains the following elements, as applicable:[^1]
 - Summary
 - Requirements
 - Detailed specifications
 - References to the C standard library
@@ -76,11 +78,11 @@ 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.
@@ -104,43 +106,49 @@ The detailed specifications each contain the following elements:
 - restrictions on template arguments, if any
 - description of class invariants
 - description of function semantics
 Descriptions of class member functions follow the order (as
-appropriate):[^3]
 - constructor(s) and destructor
 - copying, moving & assignment functions
-- comparison functions
 - modifier functions
 - observer functions
 - 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.
@@ -170,11 +178,11 @@ 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.
@@ -188,26 +196,32 @@ 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)
@@ -225,49 +239,33 @@ constexpr auto synth-three-way =
       }
     };
   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
-namespace std {
-  extern "C" using some-handler = int(int, void*, double);  // exposition only
-}
-```
-The type placeholder `some-handler` can now be used to specify a
-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 [[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₃, … };
@@ -345,24 +343,36 @@ The following terms apply to objects and values of bitmask types:
 - The value *Y* *is set* in the object *X* if the expression *X* `&` *Y*
   is nonzero.
 ##### Character sequences <a id="character.seq">[[character.seq]]</a>
 The C standard library makes widespread use of characters and character
 sequences that follow a few uniform conventions:
 - A *letter* is any of the 26 lowercase or 26 uppercase letters in the
-  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
@@ -384,10 +394,14 @@ 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.
@@ -400,44 +414,46 @@ 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
@@ -457,5 +473,60 @@ streambuf* sb;      // exposition only
 ```
 An implementation may use any technique that provides equivalent
 observable behavior.

 ## Method of description <a id="description">[[description]]</a>
+### General <a id="description.general">[[description.general]]</a>
+Subclause [[description]] describes the conventions used to specify the
+C++ standard library. [[structure]] describes the structure of
 [[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>
+Each library clause contains the following elements, as applicable:[^2]
 - Summary
 - Requirements
 - Detailed specifications
 - References to the C standard library
 [[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.[^3]
 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.
 - restrictions on template arguments, if any
 - description of class invariants
 - description of function semantics
 Descriptions of class member functions follow the order (as
+appropriate):[^4]
 - constructor(s) and destructor
 - copying, moving & assignment functions
+- comparison operator functions
 - modifier functions
 - observer functions
 - operators and other non-member functions
 Descriptions of function semantics contain the following elements (as
+appropriate):[^5]
 - *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 can
   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 can 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 can 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; violation of any preconditions results in
+  undefined behavior.
 - *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.
+- *Result:* for a *typename-specifier*, a description of the named type;
+  for an *expression*, a description of the type of the expression; the
+  expression is an lvalue if the type is an lvalue reference type, an
+  xvalue if the type is an rvalue reference type, and a prvalue
+  otherwise.
 - *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.
 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.[^6]
 Complexity requirements specified in the library clauses are upper
 bounds, and implementations that provide better complexity guarantees
 meet the requirements.
 cross-references to the relevant portions of other standards
 [[intro.refs]].
 ### Other conventions <a id="conventions">[[conventions]]</a>
+#### General <a id="conventions.general">[[conventions.general]]</a>
+Subclause [[conventions]] 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 entities, etc. <a id="expos.only.entity">[[expos.only.entity]]</a>
+Several entities and *typedef-name*s defined in [[support]] through
+[[thread]] and [[depr]] are only defined for the purpose of exposition.
+The declaration of such an entity or *typedef-name* 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
+namespace std {
+  template<class T>
+    requires convertible_to<T, decay_t<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)
       }
     };
   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.[^7]
+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.
 ##### 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.[^8]
 The enumerated type `enumerated` can be written:
 ``` cpp
 enum enumerated { V₀, V₁, V₂, V₃, … };
 - The value *Y* *is set* in the object *X* if the expression *X* `&` *Y*
   is nonzero.
 ##### Character sequences <a id="character.seq">[[character.seq]]</a>
+###### General <a id="character.seq.general">[[character.seq.general]]</a>
 The C standard library makes widespread use of characters and character
 sequences that follow a few uniform conventions:
+- Properties specified as *locale-specific* may change during program
+  execution by a call to `setlocale(int, const char*)` [[clocale.syn]],
+  or by a change to a `locale` object, as described in [[locales]] and
+  [[input.output]].
+- The *execution character set* and the *execution wide-character set*
+  are supersets of the basic literal character set [[lex.charset]]. The
+  encodings of the execution character sets and the sets of additional
+  elements (if any) are locale-specific. Each element of the execution
+  wide-character set is encoded as a single code unit representable by a
+  value of type `wchar_t`. \[*Note 1*: The encodings of the execution
+  character sets can be unrelated to any literal
+  encoding. — *end note*]
 - A *letter* is any of the 26 lowercase or 26 uppercase letters in the
+  basic character set.
+- The *decimal-point character* is the locale-specific (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.
 - 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
 A *static NTBS* is an NTBS with static storage duration.[^10]
 ###### Multibyte strings <a id="multibyte.strings">[[multibyte.strings]]</a>
+A *multibyte character* is a sequence of one or more bytes representing
+the code unit sequence for an encoded character of the execution
+character set.
 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.
 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 effects of invoking different instances
+of a specific customization point object type on the same arguments are
+equivalent.
+The type `T` of a customization point object, ignoring *cv-qualifier*s,
+shall model `invocable<T&, Args...>`, `invocable<const T&, Args...>`,
+`invocable<T, Args...>`, and `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.
+For a given customization point object `o`, let `p` be a variable
+initialized as if by `auto p = o;`. Then for any sequence of arguments
+`args...`, the following expressions have effects equivalent to
+`o(args...)`:
+- `p(args...)`
+- `as_const(p)(args...)`
+- `std::move(p)(args...)`
+- `std::move(as_const(p))(args...)`
 Each customization point object type constrains its return type to model
 a particular concept.
 #### 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
 ```
 An implementation may use any technique that provides equivalent
 observable behavior.
+#### Freestanding items <a id="freestanding.item">[[freestanding.item]]</a>
+A *freestanding item* is a declaration, entity, *typedef-name*, or macro
+that is required to be present in a freestanding implementation and a
+hosted implementation.
+Unless otherwise specified, the requirements on freestanding items for a
+freestanding implementation are the same as the corresponding
+requirements for a hosted implementation, except that not all of the
+members of the namespaces are required to be present.
+[*Note 1*: This implies that freestanding item enumerations have the
+same enumerators on freestanding implementations and hosted
+implementations. Furthermore, class types have the same members and
+class templates have the same deduction guides on freestanding
+implementations and hosted implementations. — *end note*]
+A declaration in a header synopsis is a freestanding item if
+- it is followed by a comment that includes *freestanding*, or
+- the header synopsis begins with a comment that includes *all
+  freestanding*.
+An entity or *typedef-name* is a freestanding item if it is:
+- introduced by a declaration that is a freestanding item,
+- an enclosing namespace of a freestanding item,
+- a friend of a freestanding item,
+- denoted by a *typedef-name* that is a freestanding item, or
+- denoted by an alias template that is a freestanding item.
+A macro is a freestanding item if it is defined in a header synopsis and
+- the definition is followed by a comment that includes *freestanding*,
+  or
+- the header synopsis begins with a comment that includes *all
+  freestanding*.
+[*Example 1*:
+``` cpp
+#define NULL see below      // freestanding
+```
+— *end example*]
+[*Example 2*:
+``` cpp
+// all freestanding
+namespace std {
+```
+— *end example*]

Diff to HTML by rtfpessoa