[concepts.equality] - C++20 → C++23

Files changed (1) hide show

tmp/tmpyuqr8vhb/{from.md → to.md} +19 -16

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

@@ -7,25 +7,28 @@ expression’s result and all operands modified by the expression. For the
 purposes of this subclause, the operands of an expression are the
 largest subexpressions that include only:
 - an *id-expression* [[expr.prim.id]], and
 - invocations of the library function templates `std::move`,
-  `std::forward`, and `std::declval` ([[forward]], [[declval]]).
 [*Example 1*: The operands of the expression `a = std::move(b)` are `a`
 and `std::move(b)`. — *end example*]
-Not all input values need be valid for a given expression; e.g., for
-integers `a` and `b`, the expression `a / b` is not well-defined when
-`b` is `0`. This does not preclude the expression `a / b` being
-equality-preserving. The *domain* of an expression is the set of input
-values for which the expression is required to be well-defined.
-Expressions required by this document to be equality-preserving are
-further required to be stable: two evaluations of such an expression
-with the same input objects are required to have equal outputs absent
-any explicit intervening modification of those input objects.
 [*Note 1*: This requirement allows generic code to reason about the
 current values of objects based on knowledge of the prior values as
 observed via equality-preserving expressions. It effectively forbids
 spontaneous changes to an object, changes to an object from another
@@ -33,18 +36,18 @@ thread of execution, changes to an object as side effects of
 non-modifying expressions, and changes to an object as side effects of
 modifying a distinct object if those changes could be observable to a
 library function via an equality-preserving expression that is required
 to be valid for that object. — *end note*]
-Expressions declared in a *requires-expression* in this document are
-required to be equality-preserving, except for those annotated with the
-comment “not required to be equality-preserving.” An expression so
 annotated may be equality-preserving, but is not required to be so.
 An expression that may alter the value of one or more of its inputs in a
 manner observable to equality-preserving expressions is said to modify
-those inputs. This document uses a notational convention to specify
 which expressions declared in a *requires-expression* modify which
 inputs: except where otherwise specified, an expression operand that is
 a non-constant lvalue or rvalue may be modified. Operands that are
 constant lvalues or rvalues are required to not be modified. For the
 purposes of this subclause, the cv-qualification and value category of
@@ -58,11 +61,11 @@ rvalue for the given operand are also required except where such an
 expression variation is explicitly required with differing semantics.
 These *implicit expression variations* are required to meet the semantic
 requirements of the declared expression. The extent to which an
 implementation validates the syntax of the variations is unspecified.
-[*Example 2*:
 ``` cpp
 template<class T> concept C = requires(T a, T b, const T c, const T d) {
   c == d;           // #1
   a = std::move(b); // #2
@@ -98,11 +101,11 @@ For the above example:
   second operand, since expression \#2 already specifies exactly such an
   expression explicitly.
 — *end example*]
-[*Example 3*:
 The following type `T` meets the explicitly stated syntactic
 requirements of concept `C` above but does not meet the additional
 implicit requirements:

 purposes of this subclause, the operands of an expression are the
 largest subexpressions that include only:
 - an *id-expression* [[expr.prim.id]], and
 - invocations of the library function templates `std::move`,
+  `std::forward`, and `std::declval` [[forward]], [[declval]].
 [*Example 1*: The operands of the expression `a = std::move(b)` are `a`
 and `std::move(b)`. — *end example*]
+Not all input values need be valid for a given expression.
+[*Example 2*: For integers `a` and `b`, the expression `a / b` is not
+well-defined when `b` is `0`. This does not preclude the expression
+`a / b` being equality-preserving. — *end example*]
+The *domain* of an expression is the set of input values for which the
+expression is required to be well-defined.
+Expressions required to be equality-preserving are further required to
+be stable: two evaluations of such an expression with the same input
+objects are required to have equal outputs absent any explicit
+intervening modification of those input objects.
 [*Note 1*: This requirement allows generic code to reason about the
 current values of objects based on knowledge of the prior values as
 observed via equality-preserving expressions. It effectively forbids
 spontaneous changes to an object, changes to an object from another
 non-modifying expressions, and changes to an object as side effects of
 modifying a distinct object if those changes could be observable to a
 library function via an equality-preserving expression that is required
 to be valid for that object. — *end note*]
+Expressions declared in a *requires-expression* in the library clauses
+are required to be equality-preserving, except for those annotated with
+the comment “not required to be equality-preserving.” An expression so
 annotated may be equality-preserving, but is not required to be so.
 An expression that may alter the value of one or more of its inputs in a
 manner observable to equality-preserving expressions is said to modify
+those inputs. The library clauses use a notational convention to specify
 which expressions declared in a *requires-expression* modify which
 inputs: except where otherwise specified, an expression operand that is
 a non-constant lvalue or rvalue may be modified. Operands that are
 constant lvalues or rvalues are required to not be modified. For the
 purposes of this subclause, the cv-qualification and value category of
 expression variation is explicitly required with differing semantics.
 These *implicit expression variations* are required to meet the semantic
 requirements of the declared expression. The extent to which an
 implementation validates the syntax of the variations is unspecified.
+[*Example 3*:
 ``` cpp
 template<class T> concept C = requires(T a, T b, const T c, const T d) {
   c == d;           // #1
   a = std::move(b); // #2
   second operand, since expression \#2 already specifies exactly such an
   expression explicitly.
 — *end example*]
+[*Example 4*:
 The following type `T` meets the explicitly stated syntactic
 requirements of concept `C` above but does not meet the additional
 implicit requirements:

Diff to HTML by rtfpessoa