Vision for the D language - stabilizing complexity?

ag0aep6g via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 13 05:15:07 PDT 2016


On 07/13/2016 01:28 PM, Andrei Alexandrescu wrote:
> 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.

The obvious way doesn't seem so bad in isolation:

----
void main()
{
     S s;
     immutable int* p = &s.a;
     S* ps = cast(S*) p;
     ps.b = 42;
}
----

But when p comes from a pure function things get iffy:

----
struct S { immutable int a; int b; }

immutable(int*) f() pure
{
     S* s = new S;
     return &s.a;
}

void main()
{
     immutable int* p1 = f();
     S* ps1 = cast(S*) p1;
     ps1.b = 42;

     immutable int* p2 = f();
     S* ps2 = cast(S*) p2;
     ps2.b = 43;
}
----

f is marked pure, has no parameters and no mutable indirections in the 
return type. So f is strongly pure. That means, the compiler is free to 
reuse p1 for p2. Or it may allocate two distinct structures, of course.

So, ps1 may or may not be the same as ps2, if those casts are allowed. 
That can't be right.


More information about the Digitalmars-d mailing list