This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 109b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2022-09-25


1805. Conversions of array operands in conditional-expressions

Section: 7.6.16  [expr.cond]     Status: CD4     Submitter: Richard Smith     Date: 2013-11-02

[Moved to DR at the November, 2014 meeting.]

The final bullet of 7.6.16 [expr.cond] paragraph 3, describing the attempt to convert the operands of the conditional operator to the other operand's type as part of determining the type of the result, says,

The phrase “if E2 were converted to a prvalue” is problematic if E2 has an array type. For example,

  struct S {
    S(const char *s);
    operator const char *();
  };

  S s;
  const char *f(bool b) {
    return b ? s : "";   // #1
  }

One might expect that the expression in #1 would be ambiguous, since S can be converted both to and from const char*. However, the target type for the conversion of s is const char[1], not const char*, so that conversion fails and the result of the conditional-expression has type S.

It might be better to specify the target type for this trial conversion to be the type after the usual lvalue-to-rvalue, array-to-pointer, and function-to-pointer conversions instead of simply the result of converting “to a prvalue.”

Proposed resolution (February, 2014):

Change the final subbullet of 7.6.16 [expr.cond] paragraph 3 as follows:

...The process for determining whether an operand expression E1 of type T1 can be converted to match an operand expression E2 of type T2 is defined as follows:

[Editorial note: this wording was approved by CWG, but I'd suggest an editorial change to “...or if both have class types but the underlying classes are not the same and neither is a base class of the other.” —wmm]