Possible @property compromise

Zach the Mystic reachBUTMINUSTHISzach at gOOGLYmail.com
Fri Feb 1 19:14:23 PST 2013


On Friday, 1 February 2013 at 21:33:31 UTC, Rob T wrote:
> It's one thing to implement a struct, and another thing to 
> implement nested structs that can refer to the host instance. I 
> know some people want nested structs that can work in that way, 
> but implementation is problematic because when the host struct 
> is moved, then the nested struct has to move along with it and 
> this one reason why we don't have them.

I am not proposing this and I don't think it's actually 
necessary. My nested struct is just a tried-and-true struct. So 
what's the difference? How does it still succeed? Not because it 
contains any special data or hidden pointers unto itself. Rather, 
because its *functions* are written to *accept hidden pointers*. 
That way they can operate on whatever instance of their parent's 
type gets sent to them. They could be optimized, in theory, to 
only accept pointers to instances they actually worked on. For 
example, if a nested member function did nothing but set an 
integer defined in a struct three nests up, it only need take an 
instance of that struct, but that's an advanced optimization, not 
necessary for a basic implementation which would simply pass 
three pointers to every three-deep nested struct member function. 
If you want an example, just ask.


More information about the Digitalmars-d mailing list