Order of evaluation - aka hidden undefined behaviours.

[Alex Rønne Petersen]

On 26-09-2012 19:23, Jonathan M Davis wrote:
> 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
>

I do not know any other languages than C and C++ that leave it undefined.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org