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

2024-11-11

1054. Lvalue-to-rvalue conversions in expression statements

[Voted into the WP at the March, 2011 meeting.]

C and C++ differ in the treatment of an expression statement, in particular with regard to whether a volatile lvalue is fetched. For example,

    volatile int x;
    void f() {
        x;    // Fetches x in C, not in C++
    }

The reason C++ is different in this regard is principally due to the fact that an assignment expression is an lvalue in C++ but not in C. If the lvalue-to-rvalue conversion were applied to expression statements, a statement like

    x = 5;

would write to x and then immediately read it.

It is not clear that the current approach to dealing with the difference in assignment expressions is the only or best approach; it might be possible to avoid the unwanted fetch on the result of an assignment statement without giving up the fetch for a variable appearing by itself in an expression statement.

Proposed resolution (January, 2011):

1. Add a new paragraph after Clause 7 [expr] paragraph 10:

In some contexts, an expression only appears for its side-effects. Such an expression is called a discarded-value expression. The expression is evaluated and its value is discarded. The array-to-pointer (7.3.3 [conv.array]) and function-to-pointer (7.3.4 [conv.func]) standard conversions are not applied. The lvalue-to-rvalue conversion (7.3.2 [conv.lval]) is applied only if the expression is an lvalue of volatile-qualified type and it has one of the following forms:

• id-expression (_N4567_.5.1.1 [expr.prim.general]),

• subscripting (7.6.1.2 [expr.sub]),

• class member access (7.6.1.5 [expr.ref]),

• indirection (7.6.2.2 [expr.unary.op]),

• pointer-to-member operation (7.6.4 [expr.mptr.oper]),

• conditional expression (7.6.16 [expr.cond]) where both the second and the third operand are one of the above, or

• comma expression (7.6.20 [expr.comma]) where the right operand is one of the above.

2. Change 7.6.1.9 [expr.static.cast] paragraph 6 as follows:

Any expression can be explicitly converted to type cv void, in which case it becomes a discarded-value expression (Clause 7 [expr]). The expression value is discarded. [Note: however, if the value is in a temporary object (6.7.7 [class.temporary]), the destructor for that object is not executed until the usual time, and the value of the object is preserved for the purpose of executing the destructor. —end note] 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 are not applied to the expression.

3. Change 7.6.20 [expr.comma] paragraph 1 as follows:

...A pair of expressions separated by a comma is evaluated left-to-right; and the value of the left expression is discarded a discarded-value expression (Clause 7 [expr]).⁸³ 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 are not applied to the left expression. Every value computation...

4. Change 8.3 [stmt.expr] paragraph 1 as follows:

...The expression is evaluated and its value is discarded a discarded-value expression (Clause 7 [expr]). 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 are not applied to the expression. All side effects...