This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Moved to DR at the May, 2015 meeting.]
According to 7.6.20 [expr.comma] paragraph 1,
The type and value of the result are the type and value of the right operand; the result is of the same value category as its right operand, and is a bit-field if its right operand is a glvalue and a bit-field.
The description of a bit-field result seems to indicate that the operand might not be a glvalue but could still be a bit-field. There doesn't appear to be a normative prohibition against prvalue bit-fields, so one should presumably be added, and this wording should be adjusted to remove the suggestion that such a thing might exist.
Proposed resolution (November, 2014):
Change 7.2.1 [basic.lval] paragraph 2 as follows:
Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see 7.3.2 [conv.lval], 7.3.3 [conv.array], and 7.3.4 [conv.func]. [Note: An attempt to bind an rvalue reference to an lvalue is not such a context; see 9.4.4 [dcl.init.ref]. —end note] [Note: There are no prvalue bit-fields; if a bit-field is converted to a prvalue (7.3.2 [conv.lval]), a prvalue of the type of the bit-field is created, which might then be promoted (7.3.7 [conv.prom]). —end note]
Change 7.6.20 [expr.comma] paragraph 1 as follows:
...The type and value of the result are the type and value of the right operand; the result is of the same value category as its right operand, and is a bit-field if its right operand isa glvalue anda bit-field. If the value...