struct inheritance

[kris]

Bill Baxter wrote:
> Robert Fraser wrote:
>> Bill Baxter Wrote:
>>
>>> Let us all turn our copies of WalterAndrei.pdf to page 40 where yea 
>>> verily it doth say:
>>>
>>>      struct M { int a; }
>>>      struct S {
>>>         M m;
>>>         alias m this;
>>>         int b;
>>>      }
>>>
>>> Why not just allow mixin to do this?
>>>
>>>      struct M { int a; }
>>>      struct S {
>>>         mixin M;
>>>         int b;
>>>      }
>>>
>>> That's basically the way it's done now except now it would be more like:
>>> template MMixin() { int a; }
>>> struct M { mixin M; }
>>> struct S { mixin M; int b; }
>>>
>>> Just let us treat a struct like a zero arg template for mixin purposes.
>>>
>>> --bb
>>
>> It amounts to the same thing, so it just depends on which syntax you 
>> prefer. Personally, I like...
>>
>> struct S : M { int b; }
>>
>> ... meaning S is non-polymorphically inherited from M. I guess the 
>> argument against taht syntax was that it would be confusing for people 
>> from a C++ background who assume polymorphic inheritance for structs.
>>
>> Anyways, it's up to Walter to decide on the syntax, and he says "alias 
>> this".
> 
> I did just think of one issue which is that constructors/opCalls for M 
> would be weird.  S needs to decide how to initialize the M part, which 
> would be difficult if M's constructors are just mixed in directly.
> 
> I guess from a compiler-writers perspective "alias this" is more like 
> what actually happens when you inherit in typical C++ fashion.  In that 
> case I guess I'd prefer 'import'
> 
>       struct M { int a; }
>       struct S {
>          import M;
>          int b;
>       }
> 
> then you can specify when you need to access the M parts just like you 
> do in C++ by M.member.
> 
> I'd even prefer "alias m .;" to "alias m this;".  It just seems wrong 
> and goes against the nice happy view that 'this' is just an implicitly 
> defined pointer member.
> 
> --bb

Perhaps a bigger problem is this:

#       struct M { int a; }
#       struct S {
#          int b;
#          import M;
#       }

Now, S is no longer derived from M. Hence, it would seem the right way 
to do this is to take it out of the hands of the developer and do 
something akin to

#	struct S : M

as had been suggested previously. Sure, that particular syntax may mean 
something else to some C++ folks, but at least the intent is clear and 
the /outcome/ is consistent.

BTW, did you select S&M for a specific reason? :p