Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/12/2016 6:13 AM, John Colvin wrote:
> On Tuesday, 12 July 2016 at 10:19:04 UTC, Walter Bright wrote:
>> On 7/12/2016 2:40 AM, John Colvin wrote:
>>> For the previous statement to be false, you must define cases where
>>> casting away immutability *is* defined.
>>
>> @system programming is, by definition, operating outside of the
>> language guarantees of what happens. It's up to you, the systems
>> programmer, to know what you're doing there.
>
> This is so, so wrong. There's a world of difference between "you have to
> get this right or you're in trouble" and "the compiler (and especially
> the optimiser) is free to assume that what you're doing never happens".
> Undefined behaviour, as used in practice by modern optimising compilers,
> is in the second camp. You might have a different definition, but it's
> not the one everyone else is using and not the one that our two fastest
> backends understand.
>
> Given the definition of undefined behaviour that everyone else
> understands, do you actually mean "modifying immutable data by any means
> is undefined behaviour" instead of "casting away immutable is undefined
> behaviour"?

What's the difference?

Anyhow, if you cast away immutability, and the data exists in rom, you 
still can't write to it (you'll get a seg fault). If it is in mutable 
memory, you can change it, but other threads may be caching or reading 
the value while you do that, i.e. synchronization issues. The optimizer 
may be taking advantage of immutability in its semantic transformations.

As a systems programmer, you'd have to account for that.