ISO/ IEC JTC1/SC22/WG21 p0431r0

Document: P0431R0
Date: 2016-09-14
Audience: Core

    a() << b(), a() = b(), and a() + b() are all different.
    a() = b() and a().operator=(b()) are different.
    Must a() << b() and operator<<(a(), b()) the same?

    Correcting Evaluation Order for C++

    Hyman Rosen

    The adoption of P0145 adds more order-of-evaluation rules to C++ that are
    inconsistent, difficult to teach, and break the equivalence of infix and
    functional forms of some operators.  Before it's too late, we should adopt
    a strict left-to-right order of evaluation for C++ expressions, including
    completion of side effects.  The result would be a starkly simple single
    rule that is easy to learn and remember, and the prevention of code that
    "accidentally works" but is actually unspecified.

    This paper was written with proposal P0145 (Refining Expression Evaluation
    Order for Idiomatic C++ by Gabriel Dos Reis, Herb Sutter, and Jonathan
    Caves) in view, and may copy some of its wording and examples.

    Order of evaluation of C++ expressions is a perennial source of confusion
    for programmers.  The language has a variety of rules and exceptions for
    the order of evaluation of subexpressions and the completion of side
    effects, and is inconsistent with itself (with respect to similar-appearing
    code in different contexts) and with C.  The adoption of P0145 at Oulu has
    only made the situation worse, and in such a way that it can never be
    repaired, due to its requirement that assigments evaluate the right-hand
    side before the left.

    Consider the following program:

        #include <stdio.h>
        int main() {
            int i = 0; int a[] = { ++i, ++i, ++i };
            printf("%d %d %d\n", a[0], a[1], a[2]);

    C++ (from 2011) requires that the initializers of a[] be evaluated left-to-
    right, with side effects for each initializer complete before evaluation of
    the next begins ([dcl.init.list]/4) so this program prints "1 2 3".  C
    leaves the evaluation order of these initializers and their side effects
    unspecified (Initialization 6.7.9/23); experimentally, on Linux x86,
    gcc-4.3.2 prints "3 3 3" while gcc-4.9.2 prints "1 2 3".

    Now consider this variant:

        #include <stdio.h>
        void f(int a, int b, int c) { printf("%d %d %d\n", a, b, c); }
        int main() { int i = 0; f(++i, ++i, ++i); }

    In C and C++ prior to the adoption of P0145, this has undefined behavior.
    In C++ with P0145, this program may print the digits 1, 2, and 3 in any of
    the six possible orders.

    Then consider this code:

        int &a(); int &b();
        int main() {
            a() << b();
            a() += b();
            a() == b();

    In C++ before P0145, for each full expression above a() and b() are called
    in unspecified order.  After P0145, the first expression requires that a()
    be called before b(), the second that a() be called after b(), and the last
    one remains unspecified.

    Finally, the adoption of P0145 breaks the equivalence of functional and
    infix forms of operators.  Formerly, the mechanical translation of code
    between a()@b() and operator@(a(), b()) or a().operator@(b()) did not
    change the meaning of the code, since evaluation order of a() and b() was
    unspecified for all three forms.  Now that this is no longer so, the rules
    require that in a()@=b(), b() is evaluated before a(), while in
    a().operator@=(b()), a() is evaluated before b().  It is also not clear
    from the wording of the standard whether an explicitly written
    operator@(a(),b()) must evaluate a() and b() in the same order required for

    This situation should be intolerable; the designers of Java, for example,
    corrected it by fixing the order of evaluation for all expressions to be
    strictly left-to-right.  Other languages such as C# also have fixed order
    of evaluation, but with more complex rules.  (The defensive response of
    "then use those languages" does nothing to address the problem within C++.)

    Computer programs are written in order to effect some behavior from a
    computer.  When a computer program has unspecified or undefined behavior,
    it is generally the case that the programming system will choose one of the
    set of permitted behaviors to implement, and it often does so without any
    notice to the programmer as to which has been chosen, or indeed that such a
    choice was made.  If the programmer did not realize that more than one
    choice was possible, and the programming system happened to pick the
    behavior that the programmer intended, the program now has a latent error
    that might not manifest for years, until the program is built by a system
    that makes a different choice.

    Specifying order of evaluation reduces the possibility of such latent
    errors by reducing the possible interpretations of a program.  Thus, when
    the program is built by the programming system, if its behavior matches the
    intent of the programmer, future builds will behave the same way.

    Leaving some orders unspecified, as done by P0145, does nothing to address
    this problem.

    Recall how many years it took before anyone realized that calling
    f(new T, new T) could leak resources even when the function parameters are
    smart pointers.  Over and over, we see both laypeople and experts make the
    same mistakes when it comes to unspecified and undefined order.

    The changes proposed by this document are compatible with Standard C++ as
    constituted before the acceptance of P0145, in that a conforming compiler
    is already permitted to translate a program in the way this document would

    The changes proposed by this document are additionally compatible with
    Standard C, in that a conforming C compiler is also permitted to translate
    a program in the way this document would require.

    Programs which depend on a different order of evaluation may break, but
    they are already depending on behavior not sepcified by the Standards;
    vendors may choose to provide options for specifying non-Standard orders.

    It is more important for programs to be correct and to have specified
    behavior, and to be designed for the writer and the reader of the code,
    than to be underspecified in the hope that this will enable programming
    systems to produce more performant translations.  Performance should be a
    consideration when a change would have significant impact.  This is not the
    case for evaluation order, even for function call arguments, given that
    modern systems pass arguments in registers rather than on the stack.

Assignments and Associativity:
    Given the premise that expression evaluation order should be specified,
    such specifications sometimes propose that in assignments, whether simple
    or compound, the right-hand side should be evaluated before the left.  This
    is sometimes claimed to be a consequence of associativity rules (assignment
    associates right-to-left), or because "we have to determine the value
    before we can do the assignment."  P0145 as well as C# have this order for
    assignments, while Java does not.

    The claim for associativity is wrong.  Associativity (and precedence)
    determine how an expression should be fully parenthesized, not the order in
    which subexpressions should be evaluated.  That is, given

        int &a(); int &b(); int &c();
        a() = b() = c();

    associativity tells us that the expression is parenthesized as

        a() = (b() = c());

    But given this fully parenthesized expression, there is no reason to prefer
    a regime in which c() is called first, b() second, and a() last.  Indeed,
    offered the expression parenthesized as

        (a() = b()) = c();

    this regime still requires that c() is called first, b() second, and a()
    last, demonstrating that parenthesization order is irrelevant to evaluation
    order.  In fact, assignment has "right-to-left associativity" simply to
    have the meaning of

        x = y = z;

    be "assign z to y then assign y to x" rather than "assign y to x then
    assign z to x".  It is to have such an expression assign to multiple
    variables rather than to repeatedly assign to one variable.

    The claim of "we have to determine the value before we can do the
    assignment, so we should evaluate that first" is also wrong, as
    demonstrated by the expression

        a() + b() * c();

    It is equally true that the results of b() and c() must be determined and
    multiplied before the product can be added to a(), but few would advocate
    for requiring a calling order of b(), c(), a().

Infix vs. Function Incompatibility:
    Requiring assignment to be right-to-left causes additional incompatibility.
    It is no longer possible to replace assignments of class objects using
    infix notation with their function call equivalents.  That is, given

        Klass &a(); Klass &b();
        a() = b();

    we can no longer rewrite the assignment as


    because the infix notation requires that b() be called before a() while
    the function style requires that a() be called before b().

Left to Right:
    Given the premise that expression evaluation order should be specified, and
    seeing that arguments from associativity are incorrect, it is clear that
    expressions should be evaluated strictly left-to-right.  This is the order
    in which C++ code is written and read, and it is a starkly simple rule,
    trivial to learn and impossible to forget.  Even those who believe that the
    natural order for assignments is right-hand-side before left-hand-side will
    only need to be disabused of this notion once, and will never forget.

Changes to the Standard:
    The following changes are with respect to N4606.

[intro.execution] 1.9/16
    Except where noted, evaluations of operands of individual operators and of
    subexpressions of individual expressions are
    ++sequenced left-to-right.

[] 5.2.2/5
    --The initialization of a parameter, including every associated value
    --computation and side effect, is indeterminately sequenced with respect
    --to that of any other parameter.
    ++The initialization of function parameters, including every associated
    ++value computation and side effect, is sequenced left-to-right.

[expr.mptr.oper] 5.5/4
    --Otherwise, the expression E1 is sequenced before the expression E2.

[expr.shift] 5.8/4
    --The expression E1 is sequenced before the expression E2.

[expr.ass] 5.18/1
    --The right operand is sequenced before the left operand.

    --However, the operands are sequenced in the order prescribed for the
    --built-in operator (Clause 5).