This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Voted into WP at October, 2009 meeting.]
Consider the following example:
template <typename T> const T* f(bool b) { static T t1 = T(); static const T t2 = T(); return &(b ? t1 : t2); // error? }According to 7.6.16 [expr.cond], this function iswell-formed ifT is a class type and ill-formedotherwise. If the second and third operands of a conditionalexpression are lvalues of the same class type except forcv-qualification, the result of the conditional expression isan lvalue; if they are lvalues of the same non-class typeexcept for cv-qualification, the result is an rvalue.
This difference seems gratuitous and should be removed.
Proposed resolution (June, 2009):
Change 7.6.16 [expr.cond] paragraph 3 as follows:
Otherwise, if the second and third operand have different types,and either has (possibly cv-qualified) class type,or if both arelvalues of the same type except for cv-qualification, an attemptis made to convert each of those operands to the type of the other.The process for determining whether an operand expressionE1of typeT1 can be converted to match an operand expressionE2 of typeT2 is defined as follows:
IfE2 is an lvalue:E1 can be convertedto matchE2 ifE1 can be implicitly converted(7.3 [conv]) to the type “lvalue reference toT2”, subject to the constraint that in the conversionthe reference must bind directly (9.5.4 [dcl.init.ref]) toE1.
IfE2 is an rvalue, or if the conversion above cannotbe doneand at least one of the operands has (possiblycv-qualified) class type:
...