(Note: I used 'error' instead of 'problem' in the title for obvious reasons.. ;) ).

I did some basic reading on Traits in Scala. They're similar to Interfaces in Java or C#, but they do allow for default implementation of a method.

I was wondering: can't this cause a case of the "diamond problem", which is why many languages avoid multiple inheritance in the first place?

If so, how does Scala handle this?

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Commented Apr 26, 2014 at 19:16
  • 4
    @gnat: this is a conceptual question, not a concrete problem question. If he was asking "I have this class in Scala and it's giving me problems that I think might be related to the Diamond Problem, how do I fix it?" then your comment would be appropriate, but then the question would belong on SO. :P Commented Apr 26, 2014 at 19:34
  • @MasonWheeler I did some basic reading on Scala too. And first search for "diamond" in what I've read gave me the answer: "A trait has all the features of the Java interface construct. But traits can have implemented methods on them. If you are familiar with Ruby, traits are similar to Ruby’s mixins. You can mix many traits into a single class. Traits cannot take constructor parameters, but other than that they behave like classes. This gives you the ability to have something that approaches multiple inheritance without the diamond problem". Lack of effort in this question feels rather blatant
    – gnat
    Commented Apr 26, 2014 at 19:43
  • 8
    Reading that statement doesn't tell you HOW just that it does. Commented Apr 26, 2014 at 20:05

2 Answers 2


The diamond problem is the inability to decide which implementation of the method to choose. Scala solves this by defining which implementation to choose as part of the language specifications(read the part about Scala in this Wikipedia article).

Ofcourse, same order definition could also be used in class multiple inheritance, so why bother with traits?

The reason IMO is constructors. Constructors have several limitations that regular methods don't have - they can only be called once per object, they have to be called for each new object, and a child class' constructor must call it's parent's constructor as it's first instruction(most languages will do it implicitly for you if you don't need to pass parameters).

If B and C inherit A, and D inherits B and C, and both B and C's constructors call A's constructor, then D's constructor will call A's constructor twice. Defining which implementations to choose like Scala did with methods won't work here because both B's and C's constructors must be called.

Traits avoid this problem since they don't have constructors.

  • 1
    It's possible to use C3 linearization to call the constructors once and only once - that's how Python does multiple inheritance. Off the top of my head the linearization for the D < B|C < A diamond is D -> B -> C -> A. Moreover, a google search has showed me that Scala traits can have mutable variables, so surely there's a constructor somewhere in there? But if it's using composition under the hood (I don't know, never used Scala) it's not hard to see that B and C could share on instance of A...
    – Doval
    Commented May 14, 2014 at 10:33
  • ...Traits just seem like a very concise way to express all the boilerplate that goes into combining interface inheritance and composition + delegation, which is the correct way to reuse behavior.
    – Doval
    Commented May 14, 2014 at 10:37
  • @Doval My experience of constructors in multiply inherited Python is that they're a royal pain. Each constructor can't know which order it'll be called in, so doesn't know what the signature of its parent constructor is. The usual solution is for every constructor to take a bunch of keyword arguments, and pass the unused ones onto its super constructor, but if you need to work with an existing class that doesn't follow that convention, you can't safely inherit from it.
    – James_pic
    Commented Oct 8, 2015 at 9:17
  • Another question is that why C++ did not choose sane policy for diamond problem?
    – user
    Commented Apr 19, 2016 at 23:27

Scala avoids the diamond problem by something called "trait linearization". Basically, it looks up the method implementation in the traits you extend from right to left. Simple example:

trait Base {
   def op: String

trait Foo extends Base {
   override def op = "foo"

trait Bar extends Base {
   override def op = "bar"

class A extends Foo with Bar
class B extends Bar with Foo

(new A).op
// res0: String = bar

(new B).op
// res1: String = foo

Having said that, the list of traits it looks up might contain more than the ones you explicitly gave, since they might extend other traits. A detailed explanation is given here: Traits as stackable modifications and a more complete example of the linearization here: Why not multiple inheritance?

I believe in other programming languages this behavior is sometimes referred to as "Method resolution order" or "MRO".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.