why does vb.net not support multiple inheritance?

Question

I've seen some discussion on why c# does not implement multiple inheritance but very little as to why it isn't supported in vb. I understand that both c# and vb are compiled down to intermediary language and so they both need to share similar restrictions.

The lack of multiple inheritance in VB seems to have been given as one reason for the lack of the feature in dot net. Does anyone know why VB doesn't support multiple inheritance? I'm hoping for a bit of history lesson and discussion on why this was never considered for VB.

Answer 1

All dotNET languages share a Common Type System, and that CTS does not support multiple inheritance. A specific language like VB or C# cannot add this on its own, it would become incompatible with the rest of dotNET. At the most a language might select to ignore/hide such a feature.

I don't know exactly why this wasn't included but it's worth noticing that most languages don't support it. I only know of C++, and while the basic application is simple and sometimes useful it also bring a boatload of special syntax and rules along. Not everybody considers it worth the price.

Answer 2

The lack of MI (Multiple Inheritance) is greatly tied to both the language-design and the intended host (CLR):

1) The difference in MI/SI is so fundamental to a language that it is very difficult (or perhaps impossible) to 'add it as a feature' later.

2) As for the intended host: while it would be possible to write a MI language for the CLR (just as it would be possible to write a language with continuations, etc, for the CLR -- it can be done) is that, in doing so, you lose interoperability with all the other ".NET" languages.

A much easier form of "MI" that can be retrofitted into the CLR is Traits handled via compile-time MRO collapsing (This is how Scala supports Traits on the JVM). However, this still requires major redesign/rethink of the language, and for something as 'vetted' as VB(.NET), good luck :-) Having to make sure that it plays nice with existing code is a big deal when adding improvements to a language.

Answer 3

It isn't implemented in the CLR so it isn't available in CLS-compliant languages like VB.NET. There seems to be a general consensus among engineers at Microsoft, including Anders Hejlsberg, C# lead architect, that the potential benefits are not worth the cost and complexity of implementation. Chris Brumme, a distinguished engineer on the .NET team at the time, said this back in 2004:

There are several reasons we haven't provided a baked-in, verifiable, CLS-compliant version of multiple implementation inheritance:

1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet.

2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?

3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

It's not at all clear that this feature would pay for itself. It's something we are often asked about. It's something we haven't done due diligence on. But my gut tells me that, after we've done a deep examination, we'll still decide to leave the feature unimplemented.

[Link]

Bottom line is I would not hold my breath.

For now, you can gain some if not most of the benefits of multiple implementation inheritance by inheriting multiple interfaces and delegating the implementation to a contained class instance. It's a little more work but it is the best we have right now.

I should also note that I wrote C++ full-time for several years and only leveraged multiple inheritance a couple of times in my own designs. It was handy when I needed it, but honestly I don't find myself wishing for it in C# very often.

Answer 4

There are many other techniques that prove to be vastly superior to MI, such as composition. Even in languages like C++ that do support MI, it's incredibly rare to actually see a class multiply inherit from two non-abstract base classes.