struct inheritance

[Regan Heath]

kris wrote:
> 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.

When you say "derived from M" are you referring to the ordering/layout 
of M matching that of the start of S (new fields of S therefore existing 
in the part of S which is larger than M).

I'm not sure "derived" is the right term to use, we don't want to 
confuse it with class derivation, perhaps saying "S is based on M" is 
better?  /You say potatoes I say ../

As one of the main reasons/uses for structs is to define a specific 
layout in memory, perhaps the main reason for Walters syntax is to make 
it possible to define that layout however required.

I think there are cases where they should match, and you should be able 
to cast from S to M (albeit with slicing and woe to the developer who 
tries to cast an array of S to M - but perhaps the cast operator can 
handle this case?).  In this case S is based on M.

I think there are also cases where you need to specify a different 
layout and in this case S would not be based on M.

Regan