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
{{ message }}
Repository navigation
CWG2865 [expr.cond] Conditional operator with glvalue and prvalue of class type #442
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.
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).
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[/+]on Jun 18, 2024
Activity
eisenwave commentedon Apr 19, 2024
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).
[-][expr.cond] Conditional operator with glvalue and prvalue of class type[/-][+]CWG2865 [expr.cond] Conditional operator with glvalue and prvalue of class type[/+]jensmaurer commentedon Jun 18, 2024
This should be addressed by CWG2865; if there is a remaining issue, please tell me.