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

Files changed (1) hide show

tmp/tmpmrohnbat/{from.md → to.md} +16 -10

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

@@ -1,10 +1,10 @@
 ### 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
@@ -69,11 +69,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.
@@ -97,43 +97,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.
@@ -163,11 +169,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.

 ### 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.

Diff to HTML by rtfpessoa