Can we just have struct inheritence already?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Mon Jun 10 08:33:55 UTC 2019
On Sunday, 9 June 2019 at 22:05:48 UTC, Manu wrote:
> Such a dependency reeks of polymorphism-proper, maybe you're
> using the wrong tool?
> Anyone can write bad code... if your code is brittle in that
> way, then
> you'll find out soon enough when someone does that!
Well, I was speaking in general, not really related to my code
;-).
In the general case you would want a strict type system (well
unless you mark a region as bypassing the type system). C++
inherited a weak type system from C and has tried to make it
stricter, but with quite a bit of weirdness.
Type systems are difficult to design, and very difficult to
evolve one piece at a time…
> It might also be impossible to inhibit direct assignment of the
> base.
> There may be some practical limitations that we can design that
> make
> such mistakes relatively less unlikely or easy to catch.
Absolutely, you have to list all the use cases you want to cover.
Then look for a solution.
The best solution would probably require constraint based
sub-typing combined with some kind of flow-typing, but that is
out of reach, so something simpler will have to do.
A key point that is often missed in such discussions is that for
code to be readable, you should be able to tell "roughly" what a
data structure is all about by glancing at it. Which is itself is
a good reason to provide inheritance.
Anyway, you might need language changes to allow inheritance with
"merging":
struct A { char a; /* 3 unused bytes */ double b; }
struct B : A { char c; }
Should result in { char a; char c; /*3 unused bytes*/ double b;}
But that will fail if assignment to A is done with blitting.
So, I am bit sceptical of evolving languages in the way that
C++/D evolves. C++ has a problem with installed base, though, so
it is "maintenance mode"… D does not really have that problem.
More information about the Digitalmars-d
mailing list