Property discussion wrap-up

[Era Scarecrow]

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