The Atom Consists of Protons, Neutrons and Electrons

[Era Scarecrow]

On Tuesday, 5 February 2013 at 18:58:23 UTC, John Colvin wrote:
> On Tuesday, 5 February 2013 at 00:23:42 UTC, Zach the Mystic 
> wrote:
>>
>> Smash.
>
> I'm no expert but this is appears a quite comprehensive 
> solution. I like the emphasis on improving the underlying 
> mechanisms of the language (i.e. structs) in order to 
> facilitate the special case (properties).
>
> Anyone else care to comment?

  I had very little to offer in response. I agree the whole 
proposal seems quite good, similar to mine; It still has a C-like 
language feel to it compared to other proposals.

  It should refuse to compile when you return a nested struct that 
leaves the area of the struct's control or influence. This is to 
reserve stack integrity and remove obvious stack related bugs. I 
think this covers most of the cases.

   struct X {
     struct S {}
     S xs;
   }

   X.S func(ref X.S s) {
     X.S s2;
     X.S s3 = s.xs; //s3 has s's hidden pointer
     X x;
     X x2 = new X();
     return s;  //fine
     return s2; //should fail, exists only on this level
     return s3; //if it can confirm that s3's parent exists
                //outside this function. This will compile.
     return x.xs;  //fails (local stack)
     return s.xs;  //okay
     return x2.xs; //heap referenced, okay. Struct may have
                   //added internal pointer in struct rather
                   //than passed via silent function parameter.
                   //two versions of structs compiled for this 
case?
   }

   X.S func(X x) {
     return x.xs;  //fails, x is local copy
     return x;     //parent and all copied, fine.
   }

   X.S func(X.S s) {
     return s;     //passes, although s is a temp/local copy
                   //it's parent/hidden pointer is still valid
   }

   If auto ref is accepted, it should be disallowed for nested 
structs as the temporary parent's existence would cease to exist 
while the nested struct returns.

   X.S func(auto ref X.S s) {
     return s;     //Fail!
   }

   X.S func(auto ref X x) {
     return x.xs;  //Also Fail!
   }

   //both are unsafe and uncertain.
   auto xs =  func(X().xs);
   auto xs2 = func(X());



  As for the alternate syntax, for struct/one instantiation, it 
feels backwards, yet at the same time it feels correct. Is the 
struct name the same as the instantiation name? Seems breaking 
both if it is. If it isn't, then...?

   struct S {
     x struct {
     }
   }

   void func(S.x x); //struct name is... ??

  Would hate to use templates to determine this, although if it's 
more a name space than a actual struct then it may not be 
needed/wanted, and may just be a silent consequence of using the 
syntax. Maybe this was already in the proposal (I can't recall 
and don't have time to re-read it all to find out right now).