On 4 June 2012 23:37, Jonathan M Davis <[email protected]> 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';
