Everyone who writes safety critical software should read this

[bearophile]

Andrei Alexandrescu:

> Actually he only agrees partially.

I didn't know this.


> In the expression:
>
> a[i++] = i++;
>
> Walter argues "evaluate right-hand side first, then left-hand 
> side, then assign". I argue "evaluate left-to-right 
> regardless". I suspect this extends to other cases, such as:
>
> functions[i++](i++);
>
> (assuming functions is an array of functions). I argue that LTR 
> is the one way to go. Not sure he'd agree. Similarly:
>
> objects[i++].method(i++);
>
> (assuming objects is an array of objects). Here again I think 
> LTR is the simplest and most intuitive rule.

Where it's too much hard for us to tell what's the most intuitive 
behavour, it means the code is very anti-intuitive. Such code is 
going to make me scratch my head regardless what rule the D 
compiler will follow. So it's code that I refactor mercilessly to 
make it clear enough, splitting it in as many lines as needed. 
All this means that too much complex cases can be disallowed 
statically by the D compiler. This could break a little of code, 
but it's D code that today relies on undefined behavour, so 
turning it into a syntax error it's actually an improvement. So 
what I am saying is to define semantics for the normal cases, and 
just statically disallow the hardest cases.


> I think someone should sit down and define behavior for all 
> such cases, then proceed and implement it in the front-end. I 
> haven't done significant front end work so I don't know what 
> that entails.

Timon Gehr has a sharp mind that seems fit to spot most of those 
cases, with some help from others, like Kenji. So that can be a 
first step. Perhaps a little DIP could be handy to keep such 
ideas.

Bye,
bearophile