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

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.