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

Files changed (1) hide show

tmp/tmppnxps08b/{from.md → to.md} +90 -50

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

@@ -14,59 +14,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
@@ -86,58 +109,75 @@ 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.

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

Diff to HTML by rtfpessoa