struct inheritance

[kris]

Regan Heath wrote:
> 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


Briefy:

ok, S /extends/ M :)

The ordering becomes an issue when you have a pointer to S, and wish to 
use it as a pointer to an M. That's why, in C, the super-struct is 
manually inserted as the first struct member. If you manually insert the 
super-struct as the second or third member then, obviously, your pointer 
is not convertible