struct inheritance

[Bill Baxter]

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. 

Well for the 'import' syntax it wouldn't be so bad.  The compiler could 
just say "imported members will always appear first".  With the alias 
syntax that would be a bit weirder since there's already an "M m" right 
there in the struct (which I assume you would still be able to access 
via the .m).  Since there's a visible member there, it makes less sense 
for the compiler to move the fields around.


> 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.

Yeh.  I agree.  I think that syntax would be better too.  I was just 
assuming that *not* using that syntax was something that we wouldn't 
change Walter's mind about.  But maybe there's hope.


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

You'll have to ask Walter about that :-)  It's right from their 
presentation.

--bb