On Saturday, 2 February 2013 at 03:14:30 UTC, Zach the Mystic
wrote:
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.
I mean a code example. But since I'm already here:
struct A
{
int _a = 1;
B b;
struct B
{
int _b = 1;
C c;
struct C
{
int_c = 1;
int myMemberFunction() { return _a + _b + _c; }
}
}
}
How does myMemberFunction know about _a and _b? Because its
implementation is actually:
int myMemberFunction(ref A __a, ref A.B __b, ref A.B.C __c) {
return __a._a + __b._b + __c._c; }
I do find it frustrating that his kind of thing is necessary to
get full compatibility between structs and properties, which
would be so elegant.
Usage would be:
A a;
assert(a.b.c.myMemberFunction() == 3);
...which is secretly translated to this:
assert(A.B.C.myMemberFunction(a, a.b, a.b.c) == 3);
