You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue description: When a conditional expression's second and third operands have the same class type except for cv-qualification, where one is a glvalue and the other a prvalue, the result should always be a prvalue of the cv-combined type. However, the current wording doesn't always seem to yield the correct result.
Suppose the second operand is an xvalue of const X and the third operand is a prvalue of X. Under [expr.cond]/4, the conversion of the third operand to const X&& can be done, as it's a direct reference binding. The conversion from the second operand to X can also be done, using the copy constructor of X. So this would seem to yield an ambiguity. In reality, MSVC gives an xvalue of const X as the result, whereas Clang and GCC give a prvalue of const X.
Now suppose the second operand is an xvalue of X and the third operand is a prvalue of const X. The conversion of the second operand to const X can be done. In the other direction, because there's no implicit conversion sequence from prvalue of const X to X&&, bullet 4.3.3 applies, and the target type is X. This conversion can also be done using the copy constructor. Again the rules yield an ambiguity, but all implementations agree that the result is a prvalue of const X.
Suggested resolution: Add a paragraph before [expr.cond]/4:
Otherwise, if the second and third operands have class types cv1T1 and cv2T2 and at least one of the two is a prvalue, where either T1 and T2 are the same class or one is derived from the other, then both the second and third operands are implicitly converted to cvB, where cv is the union of cv1 and cv2, and B is T1 if T1 is either the same as T2 or a base class of T2, or T2 otherwise. The converted operands are used in place of the original operands for the remainder of this subclause. If either conversion cannot be performed or is ill-formed, the program is ill-formed.
The text was updated successfully, but these errors were encountered:
I second this. I've run into this exact scenario with https://stackoverflow.com/a/78354636/5740428 and also concluded that it's ill-formed according to the current wording, but compilers make it work anyway (but diverge).
jensmaurer
changed the title
[expr.cond] Conditional operator with glvalue and prvalue of class type
CWG2865 [expr.cond] Conditional operator with glvalue and prvalue of class type
Jun 18, 2024
Full name of submitter: Brian Bi
Reference (section label): [expr.cond]
Issue description: When a conditional expression's second and third operands have the same class type except for cv-qualification, where one is a glvalue and the other a prvalue, the result should always be a prvalue of the cv-combined type. However, the current wording doesn't always seem to yield the correct result.
Suppose the second operand is an xvalue of
const X
and the third operand is a prvalue ofX
. Under [expr.cond]/4, the conversion of the third operand toconst X&&
can be done, as it's a direct reference binding. The conversion from the second operand toX
can also be done, using the copy constructor ofX
. So this would seem to yield an ambiguity. In reality, MSVC gives an xvalue ofconst X
as the result, whereas Clang and GCC give a prvalue ofconst X
.Now suppose the second operand is an xvalue of
X
and the third operand is a prvalue ofconst X
. The conversion of the second operand toconst X
can be done. In the other direction, because there's no implicit conversion sequence from prvalue ofconst X
toX&&
, bullet 4.3.3 applies, and the target type isX
. This conversion can also be done using the copy constructor. Again the rules yield an ambiguity, but all implementations agree that the result is a prvalue ofconst X
.Suggested resolution: Add a paragraph before [expr.cond]/4:
The text was updated successfully, but these errors were encountered: