C++ traps that D2 doesn't avoid yet?

[Walter Bright]

bearophile wrote:
> or
> probably worse having to assign a different semantics to some C
> syntaxes (Walter has explained that this is sometimes dangerous
> because most programmers know C/C++/Java and not D, but seeing the
> huge troubles C++ has gone to be as much compatible as possible with
> C I'd say that keeping the original C semantics when it is known to
> cause troubles is _always_ bad. In such situations I prefer a
> language that acts correctly than one that acts badly just to be like
> C, and maybe I don't even like a language that doesn't use some handy
> C syntax just because the semantics is now different).

The trouble with this is when translating code. For example, take the 
md5 algorithm which is published in C, and translate it to D. It has 
some fairly complex arithmetic expressions in them. Do you know how they 
work? I don't. I have no idea. I doubt hardly anyone interested in 
translating them does.

This means that if the meaning of an expression *silently* is altered by 
transliterating them to D, the new md5.d will give wrong results and it 
will be very difficult for the programmer to figure out where the 
problem is.

This is why when D changes the semantics, it tries to restrict itself to 
changes that will produce compile time errors if the C is not 
transliterated correctly. For example, the C-style cast gives an error 
when it appears in D code, which prompts the user that some changes are 
necessary.