Conditional operator and cv-qualified class prvalues
7.6.16 [expr.cond]
Richard Smith

Created on 2016-09-06.00:00:00 last changed 20 months ago


Date: 2018-03-15.00:00:00

Proposed resolution (March, 2018):

Change 7.6.16 [expr.cond] bullet 4.3 as follows:

...Attempts are made to form an implicit conversion sequence from an operand expression E1 of type T1 to a target type related to the type T2 of the operand expression E2 as follows:

  • ...

  • If E2 is a prvalue or if neither of the conversion sequences above can be formed and at least one of the operands has (possibly cv-qualified) class type:

    • if T1 and T2 are the same class type (ignoring cv-qualification), or one is a base class of the other, and T2 is at least as cv-qualified as T1 , the target type is T2,

    • otherwise, if T2 is a base class of T1, the target type is cv1 T2, where cv1 denotes the cv-qualifiers of T1,

    • otherwise, the target type is the type that E2 would have after applying the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions.

Date: 2018-06-15.00:00:00

[Accepted as a DR at the June, 2018 (Rapperswil) meeting.]

The following example is ill-formed:

  struct A {};
  struct B : A {};
  using T = const B;
  A a = true ? A() : T();

We don't convert from A to T because we can't form an implicit conversion sequence. We don't convert from T to A because T is more cv-qualified (even though we could form an implicit conversion sequence). It would seem reasonable to accept this case; it seems that we should only be using cv-qualifiers as a tie-breaker if the class types are otherwise the same.

Date User Action Args
2020-12-15 00:00:00adminsetstatus: ready -> cd5
2018-04-11 00:00:00adminsetmessages: + msg6174
2018-04-11 00:00:00adminsetstatus: drafting -> ready
2016-09-06 00:00:00admincreate