Suggestion: Walter Bright, why not to implement multiple inheritance in D?

[Gregor Richards]

Arlen Albert Keshabyan wrote:
> Recently, I've started the subject about multiple inheritance in D. I've got
> the answers. But those solutions are not enough suitable for my purposes. Then
> I thought, why not to implement the feature which is on demand by programmers
> in D? Multiple inheritance is needed indeed just only by seeing the attempts
> of programmers to emulate it in D. It means they need it. Multiple inheritance
> is really not that bad thing which is supposed to be got rid of. Just a linear
> multiple inheritance with possibility to get to the every level of its
> hierarchy is enough, I think. Moreover, I'll help to port many useful C++ code
> into D much easier than now.
> 
> I know two approaches by now, but both are restrictive to feel the freedom of
> multiple inheritance.
> 
> First approach is excellent, but does not allow you to get as deep as you want
> to the class hierarchy (only super's virtual methods are accessible explicitly):
> 
> Walter, is it a matter of principle not to implement multiple inheritance in
> D?

No.

> If D is the language of practical usage then multiple inheritance must be
> considered to implement.

Yeah, obviously. I mean, who the hell uses Java or C#?

> What do you think?

Multiple inheritance is a terrible idea on at least two levels:

1) In class trees with functions or (worse yet) variables with the same 
name at different levels, it's confusing to the programmer to figure out 
what name maps to what.

2) The way OO is implemented in 99% of compiled programming languages, 
multiple inheritance is impossible. Let me explain:

// this is the structure representing an object
struct Object {
     struct ClassInfo *classInfo;
     struct RandomGarbage whateverTheLanguageNeeds;
     // variables go here
}

// this is the structure representing a class
struct ClassInfo {
     struct ClassInfo *parent;
     // <many other things>
     void **vtable;
}


vtable is an array of function pointers, like so for example
class A.vtable =
0 -> foo()
1 -> foo(int)

now imagine we have a class derived from the one described above. To 
make it usable as the base class, it has a vtable like this
class A(B).vtable =
0 -> foo()
1 -> foo(int)
2 -> bar()
3 -> bar(float)

Hey presto! If you pass in an object with this vtable, it will work for 
both, because calling the function foo just involves calling vtable[0]!


Now, imagine the multiple-inheritance scenario. We have these two classes:
class A.vtable =
0 -> foo()
1 -> foo(int)

class B.vtable =
0 -> baf()
1 -> baf(Object)

Now we'd like to make a class C derived from both A and B:
class C(A, B).vtable =
0 -> ???
1 -> ???
2 -> (C's own functions)

Now can you see the problem? We can't simply dereference vtable[0] or 
vtable[1] to get the proper function, because there are two different 
classes, each with their own vtable[0] and vtable[1].

There are solutions to this (obviously, since C++ works), but they're 
usually arcane and always inefficient.

  - Gregor Richards