On Wednesday, 30 January 2013 at 18:36:17 UTC, Dmitry Olshansky
wrote:
I have one key problem - the hidden pointer detail. In other
words how should it find the instance of the outer struct to to
access it?
struct A{
int a;
struct B{
void foo(){ a = 42; }
}
B b;
}
A a;
a.b.foo(); //how that b is supposed to know it's outer struct
without the hidden pointer?
auto x = a.b;
x.foo();// and now what?
Been thinking about that. I can only think that inner
(non-static) struts cannot be returned outside of their parent.
Passing them to something is fine, but they in turn can't return
them anywhere either.
Actually they likely can't be set anywhere outside the ownership
of the struct period; That would allow flexibility where we don't
have it.
//above struct example
class C {
A.B b; //Error, context pointer goes to type of A
//need root struct.
}
A.B func(); //Error!
ref A.B func(); //Error!
A.B* func(); //@system only, advanced programmers
void func(A.B b); //acceptable
void func(ref A.B b); //acceptable
A func(A a); //allowed
Now if one inner struct passed to another of the same struct
(but not instance of), the context pointer can only point to the
one that now owns it. For POD and other stuff this is acceptable.
struct S {
struct Inner{}
Inner[] x;
}
S s1;
S s2;
s2.x = s1.x.dup; //allowed, same structure but
//s2 owns it, pointers updated
Although it seems limiting, it actually would be quite useful.
I have a sorting algorithmn I'm testing with that would benefit
from not being forced to use static. Seeing as the inner struct
never leaves the outer struct...
struct MCS {
Range[] ranges;
static struct Range{
MCS *parent; //manually managed. More error prone.
}
}
