[expr.cond] - C++17 → C++20

Files changed (1) hide show

tmp/tmpiaqkw545/{from.md → to.md} +41 -41

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

@@ -1,43 +1,41 @@
-## Conditional operator <a id="expr.cond">[[expr.cond]]</a>
 ``` bnf
 conditional-expression:
     logical-or-expression
     logical-or-expression '?' expression ':' assignment-expression
 ```
 Conditional expressions group right-to-left. The first expression is
-contextually converted to `bool` (Clause  [[conv]]). It is evaluated and
-if it is `true`, the result of the conditional expression is the value
-of the second expression, otherwise that of the third expression. Only
-one of the second and third expressions is evaluated. Every value
-computation and side effect associated with the first expression is
-sequenced before every value computation and side effect associated with
-the second or third expression.
 If either the second or the third operand has type `void`, one of the
 following shall hold:
 - The second or the third operand (but not both) is a (possibly
-  parenthesized) *throw-expression* ([[expr.throw]]); the result is of
- the type and value category of the other. The *conditional-expression*
- is a bit-field if that operand is a bit-field.
 - Both the second and the third operands have type `void`; the result is
   of type `void` and is a prvalue. \[*Note 1*: This includes the case
   where both operands are *throw-expression*s. — *end note*]
 Otherwise, if the second and third operand are glvalue bit-fields of the
 same value category and of types *cv1* `T` and *cv2* `T`, respectively,
-the operands are considered to be of type *cv* `T` for the remainder of
-this section, where *cv* is the union of *cv1* and *cv2*.
 Otherwise, if the second and third operand have different types and
 either has (possibly cv-qualified) class type, or if both are glvalues
 of the same value category and the same type except for
 cv-qualification, an attempt is made to form an implicit conversion
-sequence ([[over.best.ics]]) from each of those operands to the type of
 the other.
 [*Note 2*: Properties such as access, whether an operand is a
 bit-field, or whether a conversion function is deleted are ignored for
 that determination. — *end note*]
@@ -46,22 +44,24 @@ Attempts are made to form an implicit conversion sequence from an
 operand expression `E1` of type `T1` to a target type related to the
 type `T2` of the operand expression `E2` as follows:
 - If `E2` is an lvalue, the target type is “lvalue reference to `T2`”,
   subject to the constraint that in the conversion the reference must
-  bind directly ([[dcl.init.ref]]) to an lvalue.
 - If `E2` is an xvalue, the target type is “rvalue reference to `T2`”,
   subject to the constraint that the reference must bind directly.
 - If `E2` is a prvalue or if neither of the conversion sequences above
   can be formed and at least one of the operands has (possibly
   cv-qualified) class type:
-  - if `T1` and `T2` are the same class type (ignoring
- cv-qualification), or one is a base class of the other, and `T2` is
- at least as cv-qualified as `T1`, the target type is `T2`,
   - otherwise, the target type is the type that `E2` would have after
-    applying the lvalue-to-rvalue ([[conv.lval]]), array-to-pointer (
-    [[conv.array]]), and function-to-pointer ([[conv.func]]) standard
     conversions.
 Using this process, it is determined whether an implicit conversion
 sequence can be formed from the second operand to the target type
 determined for the third operand, and vice versa. If both sequences can
@@ -69,11 +69,11 @@ be formed, or one can be formed but it is the ambiguous conversion
 sequence, the program is ill-formed. If no conversion sequence can be
 formed, the operands are left unchanged and further checking is
 performed as described below. Otherwise, if exactly one conversion
 sequence can be formed, that conversion is applied to the chosen operand
 and the converted operand is used in place of the original operand for
-the remainder of this section.
 [*Note 3*: The conversion might be ill-formed even if an implicit
 conversion sequence could be formed. — *end note*]
 If the second and third operands are glvalues of the same value category
@@ -82,36 +82,36 @@ and it is a bit-field if the second or the third operand is a bit-field,
 or if both are bit-fields.
 Otherwise, the result is a prvalue. If the second and third operands do
 not have the same type, and either has (possibly cv-qualified) class
 type, overload resolution is used to determine the conversions (if any)
-to be applied to the operands ([[over.match.oper]],  [[over.built]]).
-If the overload resolution fails, the program is ill-formed. Otherwise,
-the conversions thus determined are applied, and the converted operands
-are used in place of the original operands for the remainder of this
-section.
-Lvalue-to-rvalue ([[conv.lval]]), array-to-pointer ([[conv.array]]),
-and function-to-pointer ([[conv.func]]) standard conversions are
-performed on the second and third operands. After those conversions, one
-of the following shall hold:
 - The second and third operands have the same type; the result is of
   that type and the result object is initialized using the selected
   operand.
 - The second and third operands have arithmetic or enumeration type; the
-  usual arithmetic conversions are performed to bring them to a common
-  type, and the result is of that type.
 - One or both of the second and third operands have pointer type;
-  pointer conversions ([[conv.ptr]]), function pointer conversions (
-  [[conv.fctptr]]), and qualification conversions ([[conv.qual]]) are
-  performed to bring them to their composite pointer type (Clause
- [[expr]]). The result is of the composite pointer type.
-- One or both of the second and third operands have pointer to member
-  type; pointer to member conversions ([[conv.mem]]) and qualification
-  conversions ([[conv.qual]]) are performed to bring them to their
- composite pointer type (Clause  [[expr]]). The result is of the
-  composite pointer type.
 - Both the second and third operands have type `std::nullptr_t` or one
   has that type and the other is a null pointer constant. The result is
   of type `std::nullptr_t`.

+### Conditional operator <a id="expr.cond">[[expr.cond]]</a>
 ``` bnf
 conditional-expression:
     logical-or-expression
     logical-or-expression '?' expression ':' assignment-expression
 ```
 Conditional expressions group right-to-left. The first expression is
+contextually converted to `bool` [[conv]]. It is evaluated and if it is
+`true`, the result of the conditional expression is the value of the
+second expression, otherwise that of the third expression. Only one of
+the second and third expressions is evaluated. The first expression is
+sequenced before the second or third expression [[intro.execution]].
 If either the second or the third operand has type `void`, one of the
 following shall hold:
 - The second or the third operand (but not both) is a (possibly
+  parenthesized) *throw-expression* [[expr.throw]]; the result is of the
+  type and value category of the other. The *conditional-expression* is
+  a bit-field if that operand is a bit-field.
 - Both the second and the third operands have type `void`; the result is
   of type `void` and is a prvalue. \[*Note 1*: This includes the case
   where both operands are *throw-expression*s. — *end note*]
 Otherwise, if the second and third operand are glvalue bit-fields of the
 same value category and of types *cv1* `T` and *cv2* `T`, respectively,
+the operands are considered to be of type cv `T` for the remainder of
+this subclause, where cv is the union of *cv1* and *cv2*.
 Otherwise, if the second and third operand have different types and
 either has (possibly cv-qualified) class type, or if both are glvalues
 of the same value category and the same type except for
 cv-qualification, an attempt is made to form an implicit conversion
+sequence [[over.best.ics]] from each of those operands to the type of
 the other.
 [*Note 2*: Properties such as access, whether an operand is a
 bit-field, or whether a conversion function is deleted are ignored for
 that determination. — *end note*]
 operand expression `E1` of type `T1` to a target type related to the
 type `T2` of the operand expression `E2` as follows:
 - If `E2` is an lvalue, the target type is “lvalue reference to `T2`”,
   subject to the constraint that in the conversion the reference must
+  bind directly [[dcl.init.ref]] to a glvalue.
 - If `E2` is an xvalue, the target type is “rvalue reference to `T2`”,
   subject to the constraint that the reference must bind directly.
 - If `E2` is a prvalue or if neither of the conversion sequences above
   can be formed and at least one of the operands has (possibly
   cv-qualified) class type:
+  - if `T1` and `T2` are the same class type (ignoring cv-qualification)
+ and `T2` is at least as cv-qualified as `T1`, the target type is
+    `T2`,
+  - otherwise, if `T2` is a base class of `T1`, the target type is *cv1*
+    `T2`, where *cv1* denotes the cv-qualifiers of `T1`,
   - otherwise, the target type is the type that `E2` would have after
+    applying the lvalue-to-rvalue [[conv.lval]], array-to-pointer
+    [[conv.array]], and function-to-pointer [[conv.func]] standard
     conversions.
 Using this process, it is determined whether an implicit conversion
 sequence can be formed from the second operand to the target type
 determined for the third operand, and vice versa. If both sequences can
 sequence, the program is ill-formed. If no conversion sequence can be
 formed, the operands are left unchanged and further checking is
 performed as described below. Otherwise, if exactly one conversion
 sequence can be formed, that conversion is applied to the chosen operand
 and the converted operand is used in place of the original operand for
+the remainder of this subclause.
 [*Note 3*: The conversion might be ill-formed even if an implicit
 conversion sequence could be formed. — *end note*]
 If the second and third operands are glvalues of the same value category
 or if both are bit-fields.
 Otherwise, the result is a prvalue. If the second and third operands do
 not have the same type, and either has (possibly cv-qualified) class
 type, overload resolution is used to determine the conversions (if any)
+to be applied to the operands ([[over.match.oper]], [[over.built]]). If
+the overload resolution fails, the program is ill-formed. Otherwise, the
+conversions thus determined are applied, and the converted operands are
+used in place of the original operands for the remainder of this
+subclause.
+Lvalue-to-rvalue [[conv.lval]], array-to-pointer [[conv.array]], and
+function-to-pointer [[conv.func]] standard conversions are performed on
+the second and third operands. After those conversions, one of the
+following shall hold:
 - The second and third operands have the same type; the result is of
   that type and the result object is initialized using the selected
   operand.
 - The second and third operands have arithmetic or enumeration type; the
+  usual arithmetic conversions [[expr.arith.conv]] are performed to
+ bring them to a common type, and the result is of that type.
 - One or both of the second and third operands have pointer type;
+  pointer conversions [[conv.ptr]], function pointer conversions
+  [[conv.fctptr]], and qualification conversions [[conv.qual]] are
+  performed to bring them to their composite pointer type [[expr.type]].
+  The result is of the composite pointer type.
+- One or both of the second and third operands have pointer-to-member
+  type; pointer to member conversions [[conv.mem]], function pointer
+  conversions [[conv.fctptr]], and qualification conversions
+  [[conv.qual]] are performed to bring them to their composite pointer
+ type [[expr.type]]. The result is of the composite pointer type.
 - Both the second and third operands have type `std::nullptr_t` or one
   has that type and the other is a null pointer constant. The result is
   of type `std::nullptr_t`.

Diff to HTML by rtfpessoa