Why can't a struct inside a class access the members of that class without a this pointer? It would seem natural to me that a nested struct should probably be special in that it is really just a special container to reduce clutter in the class.

class a {
   string v;
   struct b { void fun() { writeln(v); } }
   b bb;
}

should be semantically equivalent to

class a {
   string v;
   void bb.fun() { writeln(v); }
}

(and struct b does not have to include a "this" pointer since it is passed down)

I'm in need of using structs to wrap opAssign so I can override for each variable(instead of a special method for each field in the class, which adds clutter and prevents using `=` properly). But I also want to access the class container's members. (and without having to enlarge the struct)

It seems to me that the compiler should not have any difficult treating a struct method as a class method(passing the this ptr to it) but operating on struct's data.

What's the difference between

class a {
   int x;
}

and

class a {
   struct b { alias _x this; int _x; }
   b x;
}

? (and if be is made to be used inside the class only then it seems as if it's just basically no different than using the class alone except for some simplification(has it's own op's that one unfortunately can't keep distinct from the class align since they would overlap(although it would be nice).

e.g.,


class a {
   string Name;
   void opAssign(T q) { };      // classes opAssign

   //{{ Essentially a struct here
     int x;
void opAssign_x(T q) { writeln(Name); }; // Somehow overrides = for x. ('structs' opAssign)
   //}}
}

and

class a {
   string Name;
   void opAssign(T q) { };
struct b { alias _x this; int _x; void opAssign(T q) { writeln(Name); }; } // Unfortunately we can't access Name
   b x;
}

i.e., it would seem to me that the only difference in the method opAssign of the struct is the offsets of the member variables is different(one referenced to the start of the struct and the first references them to start of the class.

Therefor we shouldn't have any issues having properties from both the *true* nested struct and directly inlining it. i.e., we should be able to access outer members(the functionality when we inline the struct into the class) AND have multiple opAssign's(or any ops) per class that can be specified for any field(which is the functionality we get when we use the struct).

Essentially what it boils down to is that nested structs do contain a this pointer to the parent class, so why can't we use it? (it's just some offset difference between the struct and class)

I do realize that nested structs are not special in the current implementation AFAIK which to me, is a waste as they should be special. In any case, is there some other way to get the same behavior in D?

One might say why don't I use classes as it solves the problem directly BUT there is a ton of wasted overhead for simply wrapping values.

I would use template mixin's but the opAssigns would clash AFAIK. The struct encapsulation lets me get the correct opAssign behavior which is what I need but prevent me from accessing the outer class members which I should be able to do.








Reply via email to