Vision for the D language - stabilizing complexity?

[John Colvin via Digitalmars-d]

On Wednesday, 13 July 2016 at 11:28:11 UTC, Andrei Alexandrescu 
wrote:
> On 7/13/16 5:19 AM, John Colvin wrote:
>> "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;
>> }
>
> Interesting distinction. We must render the latter undefined 
> but not the former. Consider:
>
> struct S { immutable int a; int b; }
> S s;
> immutable int* p = &s.a;
>
> It may be the case that you need to get to s.b (and change it) 
> when all you have is p, which is a pointer to s.a. This is 
> essentially what makes AffixAllocator work.
>
>
> Andrei

Hmm. You have to create a mutable reference to immutable data to 
do that (although you are casting away immutable). Let's consider 
this:

*(p + 1) = 3;

it either has to be written like this:

*((cast(int*)p) + 1) = 3;

or like this:

*(cast(int*)(p + 1)) = 3;

The first is creating a mutable pointer to immutable data, the 
second creates an immutable pointer to mutable data. I'm not sure 
which is worse, considering that those reference could sit around 
for ages and be passed around etc., e.g.

auto tmp = p + 1;
// ... do loads of stuff, possibly reading from tmp
*(cast(int*)tmp) = 3;

seems like we would end up in trouble (either of our own creation 
or via the optimiser) from thinking tmp actually pointed to 
immutable data. Probably worse than a mutable reference to 
immutable data, as long as you didn't write to it.

Pointer arithmetic in objects is really quite dangerous w.r.t. 
immutability/const.