Order of evaluation is (generally) not documented

[Socob]

As the title says, there seems to be a lack of documentation around order of evaluation. Currently, the only times this comes up in the documentation are:

• The order of evaluation in a chained compairson is explicitly documented to be undefined. This is partially why I think it would be important to document the more general case: Without this statement, you might not assume one way or the other what order things are evaluated in, but since one example is explicitly called out not to be defined, that kind of implies that there is some defined order in other cases.
• The defaults for keyword arguments are explicitly documented to evaluate from left to right.
• For operators, there are of course the precedence and associativity rules.
• The “nesting” of where clauses is also related in some sense and is indeed documented.

There was PR #24603 to document the order of evaluation for function arguments (which would probably cover most cases where this question might pop up), but that was closed without comment after almost 4 years? Is that simply a matter of someone finishing the work on that PR?

Also see the discussion here:
https://discourse.julialang.org/t/guarantees-on-order-of-evaluation/96259

[andrewjradcliffe]

My guess is that order of evaluation for function arguments (note: not keyword arguments) remains unspecified for a simple reason: it is an anti-pattern to rely on argument evaluation order. Order is relevant only if the evaluation of arguments produces side effects, and the order said side effects is relevant. In such a case, one should use conventional control flow constructs (if needed), or simply break the arguments onto separate lines, thereby enforcing an evaluation which meets the need. Ideally, one should separate the side effects from the argument construction step altogether.

As for rebuttals of the form "but it's clever..." -- consider yourself 6-12 months from now: will you remember all the weird things you packed into your code? not very likely.

[Socob]

If it’s preferable to leave the order of evaluation for function arguments unspecified (like in C), that’s perfectly fine with me too. My point is that either way it should be documented what guarantees there are and aren’t, especially given the similar statement about chained comparisons in the documentation I pointed out.

[vtjnash]

We are happy to specify it should be typically left to right of the parse tree result. But there are likely still some bugs

[StefanKarpinski]

I think it's fine to document it and then deal with bugs as they get reported.

[jariji]

IIUC Fortress had undefined evaluation order and evaluated expressions in parallel. It could be cool to take advantage of that in Julia too.