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

2024-12-19

1932. Bit-field results of conditional operators

[Adopted at the February, 2016 meeting.]

According to 7.6.16 [expr.cond] paragraph 3,

if the second and third operand have different types and either has (possibly cv-qualified) class type, or if both are glvalues of the same value category and the same type except for cv-qualification, an attempt is made to convert each of those operands to the type of the other. 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:

• If E2 is an lvalue: E1 can be converted to match E2 if E1 can be implicitly converted ( 7.3 [conv]) to the type “lvalue reference to T2”, subject to the constraint that in the conversion the reference must bind directly (9.4.4 [dcl.init.ref]) to an lvalue.

If two bit-field glvalues have exactly the same scalar type, paragraph 3 does not apply (two non-class operands must differ in at least cv-qualification). For an example like

  struct S {
    int i:3;
    const int j:4;
  } s;
  int k = true ? s.i : s.j;

the condition is satisfied. The intent is that S::i can be converted to const int but S::j cannot be converted to int, so the result should be a bit-field lvalue of type const int. However, the test for convertibility is phrased in terms of direct reference binding, which is inapplicable to bit-fields, resulting in neither conversion succeeding, leading to categorizing the expression as ambiguous.

Proposed resolution (October, 2015):

This issue is resolved by the resolution of issue 1895.