Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

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