Struct inheritance

[Richard (Rikki) Andrew Cattermole]

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.

> When I first saw this inheritance suggestion mentioned (possibly in a 
> recording of one of the DConf sessions), it struck me that something 
> like the 'struct embedding' together with its implicit conversion for 
> member functions on the embedded type may provide a similar mechanism.
> 
> This is something which is offered by Go/Limbo/Alef/Ken-C, the latter 
> being used as the Plan 9 C compiler.
> 
> As I recall in the latter it was used for something like:
> 
> ```C
> struct Lock {
>    ...
> };
> 
> bool lockit(struct Lock *);
> 
> struct Foo {
>     ...
>     Lock;
>     ...
> };
> 
> void something(/* ... */)
> {
>      struct Foo *foo = something_returning_Foo(/* ... */);
> 
>      if (!lockit(foo) {
>          /* some error handling */
>      }
> 
>      ...
> }
> ```
> 
> Where the use of lockit() above is then called with '&foo->Lock' as an 
> implicit conversion.

As a syntax that would imply multiple of these are possible.

Classes in D do not support multiple parent classes, so I don't think 
adding it for structs is appropriate.

If you don't need multiple parents, then the existing syntax works fine.

```d
struct Parent {
}

struct Foo : Parent {
}
```

> Personally, I'd rather have a struct like (POD) thing, even with member 
> functions, which does not allow for the possibility of classful 
> behaviour.  If classful behaviour is desired, then somehow adjust 
> classes so that they can be easily used as non-reference types.

The class behavior that I do not want here is vtables and casting. Both 
of these have very good reasons why they would not be appropriate.

So there would be differences between them with good reasons why you 
would want classes over structs still.