struct mixins

[Bill Baxter]

On Mon, Nov 16, 2009 at 11:32 AM, div0 <div0 at users.sourceforge.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Leandro Lucarella wrote:
>> struct inheritance never make it into D, for a good reason: structs are
>> not supposed to be polymorphic and inheritance is very tied to
>> polymorphism. But struct inheritance is sometimes very useful for
>> "composition", avoid an extra member when accessing to the composed type
>> members.
>>
>> Example:
>>
>> struct A {
>>       int x;
>>       int y;
>> }
>>
>> struct B {
>>       A a;
>>       int z;
>> }
>>
>> B b;
>> b.a.x = 5;
>>
>> A way to "fix" this is using template mixins:
>>
>> template Common() {
>>       int x;
>>       int y;
>> }
>>
>> struct A {
>>       mixin Common;
>> }
>>
>> struct B {
>>       mixin Common;
>>       int z;
>> }
>>
>> B b;
>> b.x = 5;
>>
>> But one can think this is even worse than the previous approach :)
>>
>> What if one could use a struct directly with mixin?
>>
>> struct A {
>>       int x;
>>       int y;
>> }
>>
>> struct B {
>>       mixin A;
>>       int z;
>> }
>>
>> B b;
>> b.x = 5;
>>
>>
>> I think this is nice, looks good, is backwards compatible, it might be
>> easy to implement (not sure about that though) and can be even extended to
>> classes (not sure about the usefulness of that either).
>>
>> The only problem are name collisions, but that can already happen with
>> template mixins, right? Anyway, collisions can yield a compile error, or
>> they might be accepted, requiring the full qualified name to access the
>> attribute, like with classes and inheritance (you can't do a mixin of the
>> same struct twice). Say A is updated in the future:
>>
>> struct A {
>>       int x;
>>       int y;
>>       int z;
>> }
>>
>> b.z = 1; // changes B.z
>> // to modify B.A.z:
>> b.A.z = 1;
>>
>>
>> I think collisions should be very rare anyways in structs.
>>
>> PS: For those who wonder, yes, this is inspired in the "embedding" feature
>>     of Google's Go, which is basically a mixin, but without adding
>>     template to the mix, it's just this, struct mixins.
>>
>>
>
> vote++
>
> I was going to suggest it when I finished my spirit port, but I was
> too lazy to in the end.
>
> It would be very handy as currently the only way support multiple
> policies is to use member vars which are basically pointers to empty
> classes, so it looks rather more ugly than it needs to be.
>
> Mixin should really go hog wild I think and let you mixin anything anywhere.


I have wanted this kind of thing before too.   I can't recall the
exact reason, but it had something to do with traits structs.  I hit
it when I was porting OpenMesh to D.

There's some base set of traits provided by the library as a struct
that you may want to add too in user code.

But I think "alias this" would probably serve that need just fine.
What use cases are served by the mixin that 'alias this' does not?
It looks like this was an attempt to explain, but I don't understand:
"See how a struct mixin could add an implicit/explicit cast to the
mixed in structs."

I guess mixin struct could allow a kind of static multiple
inheritance.  But if that's desirable, then probably alias this should
just be extended to enable that.  Seems like the two are so similar
that whatever alias this lacks in features could just be added rather
than introducing a new construct.

--bb