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