Can we just have struct inheritence already?

XavierAP n3minis-git at yahoo.es
Thu Jun 13 09:20:40 UTC 2019


On Thursday, 13 June 2019 at 06:43:44 UTC, Manu wrote:
>
> What are we so afraid of? I don't understand the resistance to 
> this *at all*... people talk about slicing, which is a pretty 
> worthless baseline argument; it's totally possible in C++ and 
> I've never heard a single case of anyone ever having that 
> problem in my life, at work, at home, or even on the internet 
> (yes, I'm sure I would find if I deliberately went looking). 
> I'm only aware the concept has a name because I've seen it 
> written in a book somewhere. It's 99.9999% 
> not-even-remotely-a-problem, it's only a 'theoretical' problem.
>
> What if we dis-allowed implicit casting structs to base type? I 
> mean, nothing else about it is polymorphic in nature... 
> not-allowing implicit casting to base type would not cause 
> problems in any use I can imagine.
>
> This should obviously be a compile error:
>   struct A { int x; }
>   struct B : A { int y; }
>   B b;
>   A a = b; // <- obviously an error

Several topics have come up that imho all may have merit and 
deserve their own threads: #1 struct inheritance/extension; #2 
bit size (related to Manu's application but in general 
independent of #1); and #3 void initialization of value types 
having unsafe consequences.

Regarding the OP abut struct inheritance, I think we need to 
specify the request better, and then discuss more objectively its 
pros and cons, and if there are advantages, what restrictions are 
needed to avoid pitfalls. We are also getting confused with 
words: we aren't placing the same meaning on the same words, 
specially "polymorphism". I will use it with the meaning of one 
type used in place of another (i.e. subtyping), while Manu seems 
to restrict the term to when this is late/dynamically bound.

I'm not clear how much polymorphism (not only dynamic) this would 
carry or we'd like it to? Not just implicit casting or copy 
constructors (again let's be general and leave the OP application 
aside), but what about passing derived structs by ref or pointer? 
And What about destructors? After all a derived struct would 
indeed have the data and methods of the base one, so it is open 
to consideration that it could be (statically) polymorphic, 
either by ref or by copy or both.

I am in favor of not being dogmatic, but if D introduced this it 
would be treading unproven territory; so it deserves a lot of 
thinking so that we don't introduce pitfalls into the language; 
but I am in favor of D having more good features and DRY.

In C++ everything is allowed of course, but a virtual destructor 
is absolutely advised when inheriting. (Besides the fact that 
dynamic polymorphism and OOP themselves are nowadays out of 
fashion with the dominant C++ and D crowds.) Most times this 
question is discussed in the context of inheriting STL 
containers, which goes at least against the design intent of the 
STL in particular; but again our question is more general.

.NET has quite the same kind of structs as D, and forbids structs 
to inherit custom types (although they can implement 
interfaces!). The CLI specification says only this is to "avoid 
dealing with the complications of value slicing ... allow for 
more efficient implementation without severely compromising 
functionality."


More information about the Digitalmars-d mailing list