> In Solidity, the order of evaluation of sub-expressions is unspecified. This means that in f(g(), h()), g() might get evaluated before h() or h() might get evaluated before g(). Practically, this order is predictable, but Solidity code shouldn’t depend on that behavior between compiler versions. In most circumstances g() is evaluated before h() (left-to-right order), which is also the behavior that most languages specify in their standards. However, in the case of emitting an event with indexed arguments, the arguments are evaluated right-to-left.
I feel that order-of-evaluation dependence is a special case of the general conflict between expression-oriented (functional-style) programming, and impure operations requiring sequential reasoning. Another case of this conflict is temporary values (expressions) with side-effectful destructors (sequential reasoning), for example https://fasterthanli.me/articles/a-rust-match-made-in-hell#w....
At this point, is it good practice to avoid using side-effectful procedure calls as parameters to other expressions (especially those with multiple inputs), but instead first assign to a temporary value to make order of operations explicit?
> In Solidity, the order of evaluation of sub-expressions is unspecified. This means that in f(g(), h()), g() might get evaluated before h() or h() might get evaluated before g(). Practically, this order is predictable, but Solidity code shouldn’t depend on that behavior between compiler versions. In most circumstances g() is evaluated before h() (left-to-right order), which is also the behavior that most languages specify in their standards. However, in the case of emitting an event with indexed arguments, the arguments are evaluated right-to-left.
I feel that order-of-evaluation dependence is a special case of the general conflict between expression-oriented (functional-style) programming, and impure operations requiring sequential reasoning. Another case of this conflict is temporary values (expressions) with side-effectful destructors (sequential reasoning), for example https://fasterthanli.me/articles/a-rust-match-made-in-hell#w....
At this point, is it good practice to avoid using side-effectful procedure calls as parameters to other expressions (especially those with multiple inputs), but instead first assign to a temporary value to make order of operations explicit?