I am really really tired of this pattern:

struct DerivedStruct
{
    static if (BaseStruct.tupleof.length > 0)
        BaseStruct base;
    else
        ref inout(BaseStruct) base() inout { return
*cast(inout(BaseStruct)*)&this; }
    alias base this;

    // derived members
    //...
}

Imagine if we could just write:

struct DerivedStruct : BaseStruct
{
    // derived members
    //...
}

Just imagine!

On Sunday, 9 June 2019 at 08:05:34 UTC, Manu wrote:

> struct DerivedStruct : BaseStruct {
>     // derived members
> }
> Just imagine!

+1

what is the problem not doing this?
copying is not to difficult: blit and call postblit for all members if they have it.
what the problem i forgot?
you want to make better C, so make code familiar for C-users.
why need this problems out of the blue?

On Sunday, 9 June 2019 at 08:05:34 UTC, Manu wrote:
> I am really really tired of this pattern:
>
> struct DerivedStruct
> {
>     static if (BaseStruct.tupleof.length > 0)
>         BaseStruct base;
>     else
>         ref inout(BaseStruct) base() inout { return
> *cast(inout(BaseStruct)*)&this; }
>     alias base this;
>
>     // derived members
>     //...
> }
>
> Imagine if we could just write:
>
> struct DerivedStruct : BaseStruct
> {
>     // derived members
>     //...
> }
>
> Just imagine!

Users would then also expect they can use the derived structures in places where there ancestors are expected, similar like with classes;)
And also they can overload the functions of this structures.
Then we need to add a monitor field to all structures to enabled it.

It seems like a small change, but opens a huge area of problems.

Kind regards
Andre

On Sunday, 9 June 2019 at 08:19:46 UTC, KnightMare wrote:

>
> what is the problem not doing this?
> copying is not to difficult: blit and call postblit for all members if they have it.
> what the problem i forgot?

Object slicing. It's a problem with inherited types when passed by value.

https://stackoverflow.com/questions/274626/what-is-object-slicing#274636

On Sunday, 9 June 2019 at 08:31:40 UTC, Andre Pany wrote:
>
> Users would then also expect they can use the derived structures in places where there ancestors are expected, similar like with classes;)
> And also they can overload the functions of this structures.
> Then we need to add a monitor field to all structures to enabled it.

not really. people will try to use keywords "virtual" or "override" and compiler will say/stop it. enough to get burned once.

On Sunday, 9 June 2019 at 08:39:09 UTC, Mike Parker wrote:
>
> Object slicing. It's a problem with inherited types when passed by value.
>
> https://stackoverflow.com/questions/274626/what-is-object-slicing#274636

in C++ this problem solved easy: cut data to base struct and u cant call methods of derived struct. nobody asks virtuals in struct

On Sunday, 9 June 2019 at 08:19:46 UTC, KnightMare wrote:
> On Sunday, 9 June 2019 at 08:05:34 UTC, Manu wrote:
>
>> struct DerivedStruct : BaseStruct {
>>     // derived members
>> }
>> Just imagine!
>
> +1
>
> you want to make better C, so make code familiar for C-users.

oops! C hasn't struct inheritance. my fault and excuse.
but it simple comfortable feature.

On Sunday, 9 June 2019 at 08:39:09 UTC, Mike Parker wrote:
> On Sunday, 9 June 2019 at 08:19:46 UTC, KnightMare wrote:
>
>>
>> what is the problem not doing this?
>> copying is not to difficult: blit and call postblit for all members if they have it.
>> what the problem i forgot?
>
> Object slicing. It's a problem with inherited types when passed by value.
>
> https://stackoverflow.com/questions/274626/what-is-object-slicing#274636

Use private inheritance of base class.

On Sunday, 9 June 2019 at 11:31:46 UTC, Ola Fosheim Grøstad wrote:
> Use private inheritance of base class.

Or add  a feature that make subclass references const so that you cannot assign to just the base class, unless the subclass explicitly allows it.

Many possibilities for preventing assignment to base class only by using static typing.

Of course, it has to be thought through.

A third option is to provide "tagged" struct where a classifier function can determine the object type and pick the right "virtual" assignment operator (using a switch statement internally).

A fourth option is to prevent sub-structs from overriding methods in the base struct and forbid assignment to be sub-struct dependent.

A fifth option would be to have abstract base structs that cannot be instantiated, and make it so it has no default methods/operators. I assume this would allow multiple inheritance of abstract base structs. You could create new abstract base structs that inherits from other abstract base structs that are non-referencable outside the abstract base struct (so that you can resolve name collisions).

On Sunday, 9 June 2019 at 08:05:34 UTC, Manu wrote:
> I am really really tired of this pattern:
>
> struct DerivedStruct
> {
>     static if (BaseStruct.tupleof.length > 0)
>         BaseStruct base;
>     else
>         ref inout(BaseStruct) base() inout { return
> *cast(inout(BaseStruct)*)&this; }
>     alias base this;
>
>     // derived members
>     //...
> }
>
> Imagine if we could just write:
>
> struct DerivedStruct : BaseStruct
> {
>     // derived members
>     //...
> }
>
> Just imagine!

You can just put the boiler plate code in a mixin template.

mixin template  BaseAs(T) {
    static if(T.tupleof.length > 0) T base;
    else                            ref inout(T) base() inout { return *cast(inout(T)*)&this; }

    alias base this;
}

struct DerivedStruct {
    mixin BaseAs!BaseStruct;
}