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