Why can't we derive struct's?

Rubn where at is.this
Thu Dec 20 02:50:20 UTC 2018


On Thursday, 20 December 2018 at 01:40:02 UTC, Manu wrote:
> I've long since become bored of this design decision. Is there 
> good
> reason for it?
> Why should it be impossible to derive a struct?
>
> It can just be a sugar for an `alias this`, but for a case of 
> simple
> inheritance, `alias this` can be tedious to spot and understand 
> when
> reading the code.
> There's also the special case of an empty base-struct. I
> **constantly** have to do this:
>
> struct Derived
> {
>   static if (Base.tupleof.length == 0)
>     ref inout(Base) base() inout { return 
> *cast(inout(Base)*)&this; }
>   else
>     Base base;
>   alias base this;
>
>   // the things...
> }
>
> If not that, then the derived class gets an aligned field of 
> nothing populated by one byte of empty base struct.
>
> It also wastes the single `alias this` slot that we get in a 
> no-multiple-alias-this world.
>
> As far as I can tell, the decision is arbitrary... can we move 
> past this?

I imagine inheritance comes with things like being able to cast a 
Derived* to Base*. How do you delete a Base* without knowing it 
is derived from? Same goes for "virtual" (C++) functions. Virtual 
destructors and all that vtable stuff you'd normally get aren't 
used in struct. Instead you need to use the class type with the 
garbage collector or some hacky work around with scoped. But 
classes organize their data any way they want, so you need to use 
a struct as a shell. Not really a because it's not possible, but 
just like we don't a lot of other stuff, it's a design decision 
that was made. Gotta poke Walter and see if he's in the "feel's 
like he doesn't owe us or anyone an explanation" kind of mood or 
not.


More information about the Digitalmars-d mailing list