LLVM talks 1: Clang for Chromium

[Walter Bright]

On 12/17/2011 2:54 AM, bearophile wrote:
> Walter:
>
>>> x = x++;
>>
>> Define order of evaluation as rvalue, then lvalue.
>
> So I presume your desire is to define the semantics of all code like that,
> and statically refuse no cases like that. This is an acceptable solution.
>
> The advantage of this solution is that it gives no restrictions on the
> acceptable D code, and it avoids complexities caused by choosing what are the
> cases to refuse statically.

I think you overlook the real advantage - how it works is guaranteed. Keep in 
mind that it is IMPOSSIBLE for any static analyzer to prove there are no order 
dependencies when the order is implementation defined.

It's trivial to write code that'll pass the static analyzer but will rely on 
implementation defined behavior. You'll always be relying on faith-based 
programming with the C/C++ approach.


> Some of its disadvantages are that programmers
> are free to write very unreadable D code that essentially only the compiler
> is able to understand,

D's approach on this allows one to reason reliably about how the code works - 
this does NOT contribute to making code unreadable.


> and that is hard to port to C/C++.

D isn't designed to be ported to C/C++. D is full of features that are not 
reasonably portable to C/C++. It's a completely irrelevant point.