Order of evaluation - aka hidden undefined behaviours.

[Jonathan M Davis]

On Wednesday, September 26, 2012 17:12:49 Alex Rønne Petersen wrote:
> On 26-09-2012 15:34, monarch_dodra wrote:
> > IMO: useful behavior would be if it was explicitly illegal to modify (or
> > modify + read) the same value twice in the same expression. I'd rather
> > expressions such as:
> > A()[] = B()[] + C()[];
> > x[i] = ++i + 1;
> > 
> > Be illegal rather than have (an arbitrarily defined) specified behavior.
> > Trying to specify a specific behavior in such cases is opening a can of
> > worms.
> 
> No it isn't. There's a perfectly sensible, sane, and intuitive fix for
> this: always evaluate arguments left-to-right. No exceptions.
> 
> It's not that complicated.

I'd still consider it to be bad practice to do anything which relies on the 
order of evaluation of function arguments, because the order is undefined in 
other languages, and if you get into the habit of doing stuff like func(++i, 
++i, ++i) in D, you're going to be screwed when you have to program in other 
languages. It's just cleaner to avoid that kind of stuff, and I'd love it if it 
were illegal (a single ++i is fine - it's using i in multiple arguments _and_ 
modifying it in one of them which is the problem). That being said, defining 
the order will at least reduce bugs, even if it's considered bad practice to 
do anything in a function call which would rely on the arguments being 
evaluated in a particular order.

- Jonathan M Davis