CWG2865 [expr.cond] Conditional operator with glvalue and prvalue of class type

[t3nsor]

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 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 cv1 T1 and cv2 T2 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 cv B, 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.

[eisenwave]

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]

This should be addressed by CWG2865; if there is a remaining issue, please tell me.