How are mixins or traits better than plain multiple inheritance?

Question

C++ has plain multiple inheritance, many language designs forbid it as dangerous. But some languages like Ruby and PHP use strange syntax to do the same thing and call it mixins or traits. I heard many times that mixins/traits are harder to abuse than plain multiple inheritance.

What specifically makes them less dangerous? Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance? Is it possible to run into the diamond problem with them?

This seems as if we were using multiple inheritance but just making excuses that those are mixins/traits so we can use them.

Answer 1

There are a number of problems with multiple inheritance when it is used with full fledged classes, but they all revolve around ambiguity.

The ambiguity shows up in a few different ways:

1. If you have two base classes with the same field x, and the derived type asks for x, what does it get?
   • If the two x variables have incongruent types, you could infer it.
   • If they're the same type, you could try to merge them into the same variable.
   • You could always expose them as weird fully qualified names.
2. If you have two base classes with the same function f with identical signatures, and someone calls f, which gets called?
   • What if the two base classes share another common virtual ancestor (the diamond problem).
   • What if the function has different, but compatible signatures?
3. When you construct a class with two base classes, which of the base classes' constructor is called first? When you destroy the object, which is killed?
4. When you lay out the object in memory, how do you do it consistently?
5. How do you handle all of these cases with 3 base classes? 10?

And that ignores things like dynamic dispatch, type inference, pattern matching and other things I know less about which become more challenging when the language supports multiple inheritance of full classes.

Traits or Mix-ins (or interfaces, or...) are all constructs which specifically limit a type's capabilities so that there is no ambiguity. They rarely own anything themselves. This allows the composition of types to go smoother because there's not two variables or two functions... there is a variable and a reference; a function and a signature. The compiler knows what to do.

The other common approach taken is to force the user to "build" (or mix in) their type one at a time. Instead of the base classes being equal partners in the new type, you add one type to another - overriding anything that was there (usually with optional syntax to re-name and/or re-expose the overridden bits).

Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance?

Depending on the language - it generally becomes troublesome or impossible to merge implementations of functions and storage for variables from multiple base classes and expose them in the derived type.

Is it possible to run into diamond problem with them?

Occasionally less severe variations will pop up based on your language, but usually no. The entire point of traits are to break that sort of ambiguity.