From Jason Turner

[expr.cond]

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp1wkngdos/{from.md → to.md} +23 -21
tmp/tmp1wkngdos/{from.md → to.md} RENAMED
@@ -51,33 +51,36 @@ type `T2` of the operand expression `E2` as follows:
51
  but an implicit conversion sequence can only be formed if the
52
  reference would bind directly.
53
  - If `E2` is a prvalue or if neither of the conversion sequences above
54
  can be formed and at least one of the operands has (possibly
55
  cv-qualified) class type:
56
- - if `T1` and `T2` are the same class type (ignoring cv-qualification)
57
- and `T2` is at least as cv-qualified as `T1`, the target type is
 
58
  `T2`,
 
59
  - otherwise, if `T2` is a base class of `T1`, the target type is *cv1*
60
- `T2`, where *cv1* denotes the cv-qualifiers of `T1`,
61
  - otherwise, the target type is the type that `E2` would have after
62
  applying the lvalue-to-rvalue [[conv.lval]], array-to-pointer
63
  [[conv.array]], and function-to-pointer [[conv.func]] standard
64
  conversions.
65
 
66
  Using this process, it is determined whether an implicit conversion
67
  sequence can be formed from the second operand to the target type
68
- determined for the third operand, and vice versa. If both sequences can
69
- be formed, or one can be formed but it is the ambiguous conversion
70
- sequence, the program is ill-formed. If no conversion sequence can be
71
- formed, the operands are left unchanged and further checking is
72
- performed as described below. Otherwise, if exactly one conversion
73
- sequence can be formed, that conversion is applied to the chosen operand
74
- and the converted operand is used in place of the original operand for
75
- the remainder of this subclause.
76
 
77
- [*Note 3*: The conversion might be ill-formed even if an implicit
78
- conversion sequence could be formed. — *end note*]
 
 
 
 
 
 
 
79
 
80
  If the second and third operands are glvalues of the same value category
81
  and have the same type, the result is of that type and value category
82
  and it is a bit-field if the second or the third operand is a bit-field,
83
  or if both are bit-fields.
@@ -89,29 +92,28 @@ to be applied to the operands [[over.match.oper]], [[over.built]]. If
89
  the overload resolution fails, the program is ill-formed. Otherwise, the
90
  conversions thus determined are applied, and the converted operands are
91
  used in place of the original operands for the remainder of this
92
  subclause.
93
 
94
- Lvalue-to-rvalue [[conv.lval]], array-to-pointer [[conv.array]], and
95
- function-to-pointer [[conv.func]] standard conversions are performed on
96
- the second and third operands. After those conversions, one of the
97
- following shall hold:
98
 
99
  - The second and third operands have the same type; the result is of
100
- that type and the result object is initialized using the selected
101
  operand.
102
  - The second and third operands have arithmetic or enumeration type; the
103
  usual arithmetic conversions [[expr.arith.conv]] are performed to
104
  bring them to a common type, and the result is of that type.
105
  - One or both of the second and third operands have pointer type;
106
- pointer conversions [[conv.ptr]], function pointer conversions
107
  [[conv.fctptr]], and qualification conversions [[conv.qual]] are
108
  performed to bring them to their composite pointer type [[expr.type]].
109
  The result is of the composite pointer type.
110
  - One or both of the second and third operands have pointer-to-member
111
- type; pointer to member conversions [[conv.mem]], function pointer
112
- conversions [[conv.fctptr]], and qualification conversions
113
  [[conv.qual]] are performed to bring them to their composite pointer
114
  type [[expr.type]]. The result is of the composite pointer type.
115
  - Both the second and third operands have type `std::nullptr_t` or one
116
  has that type and the other is a null pointer constant. The result is
117
  of type `std::nullptr_t`.
 
51
  but an implicit conversion sequence can only be formed if the
52
  reference would bind directly.
53
  - If `E2` is a prvalue or if neither of the conversion sequences above
54
  can be formed and at least one of the operands has (possibly
55
  cv-qualified) class type:
56
+ - if `T1` and `T2` are the same class type (ignoring
57
+ cv-qualification):
58
+ - if `T2` is at least as cv-qualified as `T1`, the target type is
59
  `T2`,
60
+ - otherwise, no conversion sequence is formed for this operand;
61
  - otherwise, if `T2` is a base class of `T1`, the target type is *cv1*
62
+ `T2`, where *cv1* denotes the cv-qualifiers of `T1`;
63
  - otherwise, the target type is the type that `E2` would have after
64
  applying the lvalue-to-rvalue [[conv.lval]], array-to-pointer
65
  [[conv.array]], and function-to-pointer [[conv.func]] standard
66
  conversions.
67
 
68
  Using this process, it is determined whether an implicit conversion
69
  sequence can be formed from the second operand to the target type
70
+ determined for the third operand, and vice versa, with the following
71
+ outcome:
 
 
 
 
 
 
72
 
73
+ - If both sequences can be formed, or one can be formed but it is the
74
+ ambiguous conversion sequence, the program is ill-formed.
75
+ - If no conversion sequence can be formed, the operands are left
76
+ unchanged and further checking is performed as described below.
77
+ - Otherwise, if exactly one conversion sequence can be formed, that
78
+ conversion is applied to the chosen operand and the converted operand
79
+ is used in place of the original operand for the remainder of this
80
+ subclause. \[*Note 3*: The conversion might be ill-formed even if an
81
+ implicit conversion sequence could be formed. — *end note*]
82
 
83
  If the second and third operands are glvalues of the same value category
84
  and have the same type, the result is of that type and value category
85
  and it is a bit-field if the second or the third operand is a bit-field,
86
  or if both are bit-fields.
 
92
  the overload resolution fails, the program is ill-formed. Otherwise, the
93
  conversions thus determined are applied, and the converted operands are
94
  used in place of the original operands for the remainder of this
95
  subclause.
96
 
97
+ Array-to-pointer [[conv.array]] and function-to-pointer [[conv.func]]
98
+ standard conversions are performed on the second and third operands.
99
+ After those conversions, one of the following shall hold:
 
100
 
101
  - The second and third operands have the same type; the result is of
102
+ that type and the result is copy-initialized using the selected
103
  operand.
104
  - The second and third operands have arithmetic or enumeration type; the
105
  usual arithmetic conversions [[expr.arith.conv]] are performed to
106
  bring them to a common type, and the result is of that type.
107
  - One or both of the second and third operands have pointer type;
108
+ lvalue-to-rvalue [[conv.lval]], pointer [[conv.ptr]], function pointer
109
  [[conv.fctptr]], and qualification conversions [[conv.qual]] are
110
  performed to bring them to their composite pointer type [[expr.type]].
111
  The result is of the composite pointer type.
112
  - One or both of the second and third operands have pointer-to-member
113
+ type; lvalue-to-rvalue [[conv.lval]], pointer to member [[conv.mem]],
114
+ function pointer [[conv.fctptr]], and qualification conversions
115
  [[conv.qual]] are performed to bring them to their composite pointer
116
  type [[expr.type]]. The result is of the composite pointer type.
117
  - Both the second and third operands have type `std::nullptr_t` or one
118
  has that type and the other is a null pointer constant. The result is
119
  of type `std::nullptr_t`.