Vision for the D language - stabilizing complexity?

[John Colvin via Digitalmars-d]

On Wednesday, 13 July 2016 at 00:03:04 UTC, Walter Bright wrote:
> 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?

"Casting away immutable is undefined behaviour": the following 
code has undefined results (note, not implementation defined, not 
if-you-know-what-you're-doing defined, undefined), despite not 
doing anything much:

void foo()
{
     immutable a = new int;
     auto b = cast(int*)a;
}

"modifying immutable data is undefined": The above code is fine, 
but the following is still undefined:

void foo()
{
     immutable a = new int;
     auto b = cast(int*)a;
     b = 3;
}

> 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.

Something like "it might be in ROM" is an implementation detail. 
It's the optimiser part that forces a formal decision about what 
is undefined behaviour or not.


Implementation defined behaviour is in the realm of the "systems 
programming, be careful you know what you're doing". Undefined 
behaviour is a different beast.