On Sunday, 3 February 2013 at 07:33:52 UTC, Zach the Mystic wrote:
> On Sunday, 3 February 2013 at 03:15:57 UTC, TommiT wrote:
>> On Sunday, 3 February 2013 at 02:55:44 UTC, Zach the Mystic wrote:
>>> Well, if you want access to a struct from outside, save yourself the time and put it outside to begin with. A nested struct of course is directly related to the entity it finds itself in. My pet metaphor is struct Dog containing struct Tail. It would definitely be illogical to put the Tail outside the Dog.
>>
>> If Tail is an autonomous struct/class, then it totally makes sense to put the definition of Tail outside of dog. This enables you to perhaps use the same Tail in Wolf's and Hyeena's definitions. If, on the other hand, Tail is not an autonomous type, but rather, needs to able to wag the dog, then Tail is really more like a separate logical section within Dog's definition, i.e. a namespace within Dog.
>
> A dog's tail is not an autonomous struct/class. If you ever had a dog you would know that. Also, the dog's tail is no namespace because it contains tail-specific data too.

I'm sorry, I'm just getting allergic to the word "namespace", since I don't believe any introduction of a special namespace feature in the language is required. Structs are namespaces - you got me there.

On Sunday, 3 February 2013 at 07:26:03 UTC, Zach the Mystic wrote:
> On Sunday, 3 February 2013 at 03:34:23 UTC, Era Scarecrow wrote:
>>  struct Dog {
>>    int id;
>>    struct Tail {
>>      string colorOf = "Black"; //just data.
>>      int getId() { return id; }
>>    }
>>    Tail tail;
>>
>>    void func(ref Dog rhs) {
>>      //tail2 retains context pointer to rhs.
>>      Tail tail2 = rhs.tail;
>>
>>      writeln(tail.getId());   //5
>>      writeln(tail2.getId());  //10
>>    }
>>  }
>
> There is a bug in this code and it would not compile. Your getId must receive an instance of Dog. A tail by itself has no dog. The compiler cannot rewrite tail.getId() to someImaginaryDog.tail.getId(). It's easy to think about, once you get used to it. Your getId accesses a variable defined only in its parent struct. The compiler detects this and requires receiving a hidden pointer to (and *only to!*) an instance of the parent. The resulting top-level function is:
>
> int getId(ref Dog __d) { return __d.id; }
>
> See? It may only access a dog, but it's *defined* in the tail. This is the exact behavior we're looking for, and it's easy to implement and causes no real trouble, as far as I can see.

  I don't see the bug. Tail is known to be a nested struct so it is required to have it's context (parent) attached, so it supplies it although silently; Therefore tail points to rhs & rhs.tail. This is only valid as long as the reference to rhs exists (or as long as this function exists for sure). Besides the 'id' think more it renamed to 'string dogName', therefore you can tell which tail belongs to which dog, be it sparky or scruffy, etc.

 In this case the nested struct relies on information from it's parent, but the parent doesn't need information from it's nested structs, allowing it to be correct even if the tail gets changed colors. This can have useful other effects in place like compression, maybe DB management (a text query is replaced by a compiled version of the same thing), etc.

>>  Dog dog1 = Dog(5);
>>  Dog dog2 = Dog(10); dog2.tail.colorOf = "White";
>>
>>  dog1.func(dog2);
>>
>>  //context pointer of d2 thrown away after copy,
>>  //unless opAssign is declared and does something.
>>  dog1.tail = dog2.tail;
>>
>>  assert(dog1.id == 5);   //untouched
>>  assert(dog1.tail.colorOf == "White");
>>
>>
>> At which case the tail if it's allowed to be copied should be related but not strictly required to be updated or relied on Dog for behavior.
>>
>> Guess it takes a few rules and experiments to find the right balance of accessibility vs reliability vs flexibility.
>
> With the bug removed, will any of these issues pop up? My guess is no.

 Maybe... I forget what the issues were since I went to sleep.

On Friday, 1 February 2013 at 19:59:12 UTC, Steven Schveighoffer wrote:
> Well, we can disagree, but you still haven't explained why it's fundamental.  Other languages have implemented properties just fine without having to specify that they are structs or aggregate types.  Until you come up with a compelling reason for structs, I'll stand by my position.

Do you mind if I put my arguments in a new thread?

On Monday, 4 February 2013 at 22:46:36 UTC, Zach the Mystic wrote:
> On Friday, 1 February 2013 at 19:59:12 UTC, Steven Schveighoffer wrote:
>> Well, we can disagree, but you still haven't explained why it's fundamental.  Other languages have implemented properties just fine without having to specify that they are structs or aggregate types.  Until you come up with a compelling reason for structs, I'll stand by my position.
>
> Do you mind if I put my arguments in a new thread?

FYI, I got some feedback from Andrei today in the DIP23 thread ...

--------------------
On 2/4/13 1:15 PM, Rob T wrote:
> BTW, I am wondering if the idea of "memberspaces" was considered, and if
> it was considered, then why was it dropped?

An idea that departs considerably from the current status in D has a
disadvantage compared to an idea that makes things work within the
@property framework.

Andrei
--------------------

See

http://forum.dlang.org/post/kepcjq$5fa$1@digitalmars.com

--rt