29251, "bradcray", "Should the preview edition of Chapel change the evaluation order of assignments?", "2026-08-11T23:10:13Z"
In Chapel 2.0, the order of evaluation for a simple (lhs = rhs;) or compound (lhs += rhs) assignment is to evaluate lhs first, then rhs:
The expression on the left-hand side of the assignment operator must be a valid lvalue (LValue Expressions). It is evaluated before the expression on the right-hand side of the assignment operator, which can be any expression.
This surprised me since it feels more logical. for simple assignments, to evaluate rhs before lhs since that's the direction that the computation flows ("compute rhs, store in the lhs location"). The current choice was rationalized in 8e6913c60af as following Java's lead, which was a big source of guidance for the language's early design.
This issue asks whether we should change that evaluation order in the preview edition, as it seems that Python, Rust, and Swift all evaluate rhs before lhs for simple assignments.
For compound assignments, I'm inclined to keep things as-is, as it seems logical to me to interpret lhs += rhs; as lhs = lhs + rhs which would suggest evaluating lhs first since it's the first expression on the RHS. Interestingly, though, Python and Swift continue to evaluate rhs first, whereas in Rust, it seems that the evaluation order depends on factors like the types of the expressions (and warns users against writing code that relies on the evaluation order).
The issue that ran me into this was #14287 which could be resolved by evaluating the RHS before the LHS.