Increment / Decrement Operator Behavior

[Iain Buclaw]

On 4 June 2012 23:37, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Monday, June 04, 2012 23:22:26 Bernard Helyer wrote:
>> On Monday, 4 June 2012 at 20:44:42 UTC, bearophile wrote:
>> > Bernard Helyer:
>> >> If you find yourself using postfix increment/decrement
>> >> operators in the same function call in multiple arguments,
>> >> slap yourself firmly in the face and refactor that code.
>> >
>> > I think this is not acceptable, you can't rely on that, future
>> > D programers will not slap themselves and refactor their code.
>> > Some of the acceptable alternatives are:
>> > 1) Make post/pre increments return void. This avoid those
>> > troubles. I think Go language has chosen this. This is my
>> > preferred solution.
>> > 2) Turn that code into a syntax error for some other cause.
>> > 3) Design the language so post/pre increments give a defined
>> > effect on all D compilers on all CPUs. Walter since lot of time
>> > says this is planned for D. This leads to deterministic
>> > programs, but sometimes they are hard to understand and hard to
>> > translate (port) to other languages any way. Translating code
>> > to other languages is not irrelevant because D must be designed
>> > to make it easy to understand the semantics of the code.
>> >
>> > Bye,
>> > bearophile
>>
>> If people can't be bothered to understand what they write, they
>> can go hang.
>
> I think that Bernard is being a bit harsh, but in essence, I agree. Since the
> evaluation order of arguments is undefined, programmers should be aware of that
> and code accordingly. If they don't bother to learn, then they're going to get
> bitten, and that's life.
>
> Now, Walter _has_ expressed interest in changing it so that the order of
> evaluation for function arguments is fully defined as being left-to-right,
> which solves the issue. I'd still council against getting into the habit of
> writing code which relies on the order of evaluation for the arguments to a
> function, since it's so common for other languages not to define it (so that
> the compiler can better optimize the calls), and so getting into the habit of
> writing code which _does_ depend on the order of evalution for function
> arguments will cause you to write bad code you when you work in most other
> programming languages.
>
> As for treating pre or post-increment operators specially in some manner, that
> doesn't make sense. The problem is far more general than that. If we're going
> to change anything, it would be to make it so that the language itself defines
> the order of evaluation of function arguments as being left-to-right.
>

"the language itself defines the order of evaluation of function
arguments as being left-to-right" ... if the calling convention
defines it.

For extern(D) the way you can expect order of evaluation to work in
gdc generated code - for instance - is that each argument is evaluated
from left to right, and if it has any side effects, then it is stored
into a temporary prior to calling the function.

For extern(C) the order of evaluation is actually defined by the
underlying architecture.  For example, i386 evaluates right-to-left,
however other architectures (ie: ARM) perform left-to-right evaluation
of function arguments.  Incidentally, I know there are a few tests in
the testsuite that depend on the i386 behaviour, but that is something
else to worry about.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';