D and expression evaluation order.

[Russell Lewis]

Bruno Medeiros wrote:
> Someone with a non-low average thinking capability (*grin* :) ) would 
> easily deduce that the evaluation order will be the same as any other 
> modern programming language (not just Java, but C#, Python, even Ruby, 
> have all the same evaluation order). The rule in a general sense is:

Be careful when you imply "everybody who thinks differently than I is 
stupid."  I can confidently state that I have non-low average thinking 
capability, and it is far from clear to me.  I had to look pretty hard 
at your analysis below to make sure that I knew what seemed so "obvious" 
to you.

My simple question is: why are we worrying about defining the behavior 
of code snippets which are bad coding style?  There are clearer, more 
explicit ways to accomplish the same task, that do not require that we 
define the order of operations.

>   Evaluate operands in the same order as the associativity rule of the 
> operator.
> 
> So stuff like this:
>   c = a + (b = c);
> evaluates in this order:
>   a
>   c
>   b
>   (b = c)
>   a + (b = c)
>   c
>   c = a + (b = c)
> 
> A function call, since it is basicly an operator that takes a function 
> value and arguments as operands, works in the same rule. So:
>   func(++i, ++c);
> evaluates:
>   func
>   ++i
>   ++c
>   func(++i, ++c)
> 
> I don't think there is any significant learning process involved here. 
> If you know the associativity rules (which you should), then the 
> evaluation order is simply what naturally follows from there. You don't 
> have to memorize a whole different set of rules. In fact the assignments 
> are basicly the only operators where the operands are evaluated 
> right-to-left.

If there is no significant learning process involved, then why did you 
need to state it here?  Surely everybody knew the rules already.  If not 
everybody knew the rules, there is a learning process involved...and 
apparently it's nontrivial, at least to some people.