Vision for the D language - stabilizing complexity?

[Johan Engelen via Digitalmars-d]

On Tuesday, 12 July 2016 at 09:40:09 UTC, John Colvin wrote:
> On Tuesday, 12 July 2016 at 05:37:54 UTC, Walter Bright wrote:
>> On 7/11/2016 10:15 PM, Shachar Shemesh wrote:
>>> D says any such cast is UB.
>>
>> That's why such casts are not allowed in @safe code. There's 
>> also no way to write a storage allocator in @safe code.
>>
>> Code that is not checkably safe is needed in real world 
>> programming. The difference between D and C++ here is that D 
>> provides a means of marking such code as unsafe so the rest 
>> can be checkably safe, and C++ does not.
>
> Code that *could* cause undefined behaviour given certain 
> inputs is unsafe code. Can be ok if you're careful.
>
> Code that *does* do undefined behaviour isn't just unsafe, it's 
> undefined. Never OK.
>
>
> If casting away immutability is undefined behaviour in D, then 
> all paths of execution* that do it are undefined.
>
> For the previous statement to be false, you must define cases 
> where casting away immutability *is* defined.

Strongly agree.

With `synchronize` we already have a problematic case of casting 
away immutability (dmdfe internally) where an optimizing compiler 
generates bad code. Let's not add more.