Struct inheritance

[Richard (Rikki) Andrew Cattermole]

On 04/12/2024 9:19 AM, Derek Fawcus wrote:
> On Tuesday, 3 December 2024 at 19:25:08 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 04/12/2024 8:15 AM, Derek Fawcus wrote:
>>> As I recall, the main purpose of 'alias this' is to offer implicit 
>>> conversion of types.  There is also the ability to have a member 
>>> function called (property-like?), which seems like a somewhat 
>>> different purpose.
>>
>> It is two functionalities yes.
>>
>> Which is why I've included both the inheritance as well as the 
>> reparenting behavior. Otherwise it isn't a complete replacement.
> 
>> As a syntax that would imply multiple of these are possible.
> 
> Yes, but it is literally equivalent to explicitly embedded one struct in 
> another, which is already possible.  So one could have:
> 
> ```C
> struct Foo;
> struct Bar;
> 
> struct Wrapper {
>      ...
>      Foo;
>      Bar;
>      ...
> };
> ```
> 
> Which is just sugar for this:
> 
> ```C
> struct Wrapper {
>      ...
>      struct Foo Foo;
>      struct Bar Bar;
>      ...
> };
> ```
> 
> It is just that having the embedded form allows the implicit conversion 
> to happen, as it is a simple unambiguous sugar for accessing the 
> appropriate member.

I'm very wary of this, Walter is pretty against implicit conversions 
generally speaking. I'm still trying to get a confirmation about the 
member-of-operator out of Walter which I have implemented (missing like 
two features).

Given that the utility of this is highly restricted to a subset of 
compositional needs, and the fact that it relies upon implicit 
conversions, I do not expect that this would be accepted.

However, I am in no way arguing against composition, I agree that it is 
better than inheritance normally. What this would be replacing, is not 
where composition is most valuable for.

Just in case you are interested, this is the function you would need to 
modify to implement the matching.

https://github.com/dlang/dmd/blob/d8c0e79bfb9ddb0e50603ffafa4c3d5539934f48/compiler/src/dmd/typesem.d#L998

>> Classes in D do not support multiple parent classes, so I don't think 
>> adding it for structs is appropriate.
> 
> Except D also already allows the explicit form above, but not the sugar 
> for the field reference.  This is not inheritance, so there are no 
> issues with embedding multiple structs, no diamond pattern issues, etc.  
> (I believe the Go spec explains all of this.)

I got all that. There is are issues from my perspective surrounding its 
compositional nature.

> What this gives is the implicit field conversion which 'alias this' 
> seems to offer some form of, but in a different syntactical form, and 
> allowing multiple such conversions.
> 
> However it probably won't cover all implicit conversion uses, e.g. 
> 'alias this' to an 'int' member, then assigning the struct to an int 
> var.  The scheme I'm suggesting only really covers calling functions 
> with argument conversion.

Right, its a tool for composition. Different set of problems.

>> If you don't need multiple parents, then the existing syntax works fine.
>>
>> ```d
>> struct Parent {
>> }
>>
>> struct Foo : Parent {
>> }
>> ```
> 
> Would your proposal allow:
> 
> ```d
> struct Grandad {
> }
> 
> struct Dad : Grandad {
> }
> 
> struct Child : Dad {
> }
> ```
> 
> (I'm not sure if the scheme I mention does, I'd have to reread the 
> specs; but I believe it doesn't).

Yes.