[description] - C++23 → Trunk

Files changed (1) hide show

tmp/tmpc9hzp6jm/{from.md → to.md} +180 -57

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

@@ -2,11 +2,11 @@
 ### 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>
@@ -124,54 +124,85 @@ appropriate):[^5]
   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.
 - *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*
@@ -205,27 +236,26 @@ 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)
       requires requires {
         { t < u } -> boolean-testable;
         { u < t } -> boolean-testable;
       }
@@ -238,14 +268,24 @@ namespace std {
         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
@@ -280,11 +320,11 @@ 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:
@@ -366,20 +406,22 @@ sequences that follow a few uniform conventions:
   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
   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
@@ -437,32 +479,64 @@ initialized as if by `auto p = o;`. Then for any sequence of arguments
 - `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
 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
@@ -475,58 +549,107 @@ streambuf* sb;      // exposition only
 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*]

 ### 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 [[exec]] and [[depr]]. [[conventions]] describes
 other editorial conventions.
 ### Structure of each clause <a id="structure">[[structure]]</a>
 #### Elements <a id="structure.elements">[[structure.elements]]</a>
   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*]
+- the conditions that are required for a call to the function to be a
+ constant subexpression [[defns.const.subexpr]].
+- *Preconditions:* conditions that the function assumes to hold whenever
+  it is called; violation of any preconditions results in undefined
+  behavior. \[*Example 3*: An implementation can express some such
+  conditions via the use of a contract assertion, such as a precondition
+  assertion [[dcl.contract.func]]. — *end example*]
+- conditions that the function assumes to hold whenever it is called.
+  - When invoking the function in a hardened implementation, prior to
+    any other observable side effects of the function, one or more
+    contract assertions whose predicates are as described in the
+    hardened precondition are evaluated with a checking semantic
+    [[basic.contract.eval]]. If any of these assertions is evaluated
+    with a non-terminating semantic and the contract-violation handler
+    returns, the program has undefined behavior.
+  - When invoking the function in a non-hardened implementation, if any
+    hardened precondition is violated, the program has 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. \[*Example 4*: An implementation can
+  express some such conditions via the use of a contract assertion, such
+  as a postcondition assertion [[dcl.contract.func]]. — *end example*]
 - *Result:* for a *typename-specifier*, a description of the named type;
+  for an *expression*, a description of the type and value category 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.
 - *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*, *Constant When*, *Preconditions*, *Hardened 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*
 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 defined in [[support]] through [[exec]] and [[depr]]
+are only defined for the purpose of exposition. The declaration of such
+an entity 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)       // exposition only
+        noexcept(is_nothrow_convertible_v<T, decay_t<T>>)
       { return std::forward<T>(v); }
+  constexpr auto synth-three-way =                 // exposition only
     []<class T, class U>(const T& t, const U& u)
       requires requires {
         { t < u } -> boolean-testable;
         { u < t } -> boolean-testable;
       }
         return weak_ordering::equivalent;
       }
     };
   template<class T, class U = T>
+  using synth-three-way-result =                  // exposition only
+    decltype(synth-three-way(declval<T&>(), declval<U&>()));
 }
 ```
+An object `dst` is said to be *decay-copied from* a subexpression `src`
+if the type of `dst` is
+``` cpp
+decay_t<decltype((src))>
+```
+and `dst` is copy-initialized from `src`.
 #### 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
 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 [[exec]] 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:
   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 [[exec]] 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
   element determined by some predicate. A character sequence can be
   designated by a pointer value `S` that points to its first element.
+- Let *`STATICALLY-WIDEN`*`<charT>("...")` be `"..."` if `charT` is
+  `char` and `L"..."` if `charT` is `wchar_t`.
 ###### 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
 - `p(args...)`
 - `as_const(p)(args...)`
 - `std::move(p)(args...)`
 - `std::move(as_const(p))(args...)`
+#### Algorithm function objects <a id="alg.func.obj">[[alg.func.obj]]</a>
+An *algorithm function object* is a customization point object
+[[customization.point.object]] that is specified as one or more
+overloaded function templates. The name of these function templates
+designates the corresponding algorithm function object.
+For an algorithm function object `o`, let S be the corresponding set of
+function templates. Then for any sequence of arguments `args` …,
+`o(args` … `)` is expression-equivalent to `s(args` … `)`, where the
+result of name lookup for `s` is the overload set S.
+[*Note 1*:
+Algorithm function objects are not found by argument-dependent name
+lookup [[basic.lookup.argdep]]. When found by unqualified name lookup
+[[basic.lookup.unqual]] for the *postfix-expression* in a function call
+[[expr.call]], they inhibit argument-dependent name lookup.
+[*Example 1*:
+``` cpp
+void foo() {
+  using namespace std::ranges;
+  std::vector<int> vec{1,2,3};
+  find(begin(vec), end(vec), 2);        // #1
+}
+```
+The function call expression at \#1 invokes `std::ranges::find`, not
+`std::find`.
+— *end example*]
+— *end note*]
 #### Functions within classes <a id="functions.within.classes">[[functions.within.classes]]</a>
+For the sake of exposition, [[support]] through [[exec]] 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 [[exec]] 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 [[exec]] 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
 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, 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 those items are required to be present.
+Function declarations and function template declarations followed by a
+comment that include *freestanding-deleted* are *freestanding deleted
+functions*. On freestanding implementations, it is
+*implementation-defined* whether each entity introduced by a
+freestanding deleted function is a deleted function
+[[dcl.fct.def.delete]] or whether the requirements are the same as the
+corresponding requirements for a hosted implementation.
+[*Note 1*: Deleted definitions reduce the chance of overload resolution
+silently changing when migrating from a freestanding implementation to a
+hosted implementation. — *end note*]
+[*Example 1*:
+``` cpp
+double abs(double j);           // freestanding-deleted
+```
+— *end example*]
+A declaration in a synopsis is a freestanding item if
+- it is followed by a comment that includes *freestanding*,
+- it is followed by a comment that includes *freestanding-deleted*, or
+- the header synopsis begins with a comment that includes *freestanding*
+  and the declaration is not followed by a comment that includes
+  *hosted*. \[*Note 2*: Declarations followed by *hosted* in
+  freestanding headers are not freestanding items. As a result, looking
+  up the name of such functions can vary between hosted and freestanding
+  implementations. — *end note*]
+[*Example 2*:
+``` cpp
+// all freestanding
+namespace std {
+```
+— *end example*]
+An entity or deduction guide is a freestanding item if its introducing
+declaration is not followed by a comment that includes *hosted*, and is:
 - introduced by a declaration that is a freestanding item,
+- a member of a freestanding item other than a namespace,
+- an enumerator of a freestanding item,
+- a deduction guide of a freestanding item,
 - an enclosing namespace of a freestanding item,
 - a friend of a freestanding item,
+- denoted by a type alias 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 *freestanding*
+ and the definition is not followed by a comment that includes
+  *hosted*.
+[*Example 3*:
 ``` cpp
 #define NULL see below      // freestanding
 ```
 — *end example*]
+[*Note 3*: Freestanding annotations follow some additional exposition
+conventions that do not impose any additional normative requirements.
+Header synopses that begin with a comment containing "all freestanding"
+contain no hosted items and no freestanding deleted functions. Header
+synopses that begin with a comment containing "mostly freestanding"
+contain at least one hosted item or freestanding deleted function.
+Classes and class templates followed by a comment containing "partially
+freestanding" contain at least one hosted item or freestanding deleted
+function. — *end note*]
+[*Example 4*:
 ``` cpp
+template<class T, size_t N> struct array;               // partially freestanding
+template<class T, size_t N>
+struct array {
+  constexpr reference       operator[](size_type n);
+  constexpr const_reference operator[](size_type n) const;
+  constexpr reference       at(size_type n);            // freestanding-deleted
+  constexpr const_reference at(size_type n) const;      // freestanding-deleted
+};
 ```
 — *end example*]

Diff to HTML by rtfpessoa