Why is override sometimes required for an abstract method?

Question

Based on a previous question, the following code compiles OK

trait Logger {
  def log(msg: String): Unit
}

trait LoggerA extends Logger {
  def log(msg: String) = ???
}

trait LoggerB extends Logger {
  override def log(msg: String) = ???
}

class Logged1 extends LoggerA 
class Logged2 extends LoggerB
class Logged3 extends LoggerA with LoggerB

The override is not required in LoggerA because there is no concrete implementation of log in Logger.

However if I remove the override from LoggerB it no longer compiles:

class Logged3 inherits conflicting members:
  def log(msg: String): Nothing (defined in trait LoggerA) and
  def log(msg: String): Nothing (defined in trait LoggerB)
  (note: this can be resolved by declaring an `override` in class Logged3.)

Why is override required in this specific case? Does specifying override change the method or the class in some way?

Answer 1

I guess it is specified by SLS 5.1.4 Overriding

If M′ is not an abstract member, then M must be labeled override. ... or both M and M′ override a third member M'' which is defined in a base class of both the classes containing M and M'.

Also in section 5.1.3 Class Members there is a similar use of override to OP

trait A { def f: Int }
trait B extends A { def f: Int = 1 ; def g: Int = 2 ; def h: Int = 3 }
trait C extends A { override def f: Int = 4 ; def g: Int }
trait D extends B with C { def h: Int }

thus at least it does seem a specified behaviour.

Based on fr_andres' answer and Learning Scala, Chapter 9. Objects, Case Classes, and Traits

a class extending class A and traits B and C is actually extending one class, which extends another class, which extends another class, when compiled to the .class binary file.

which due to linearization implies effectively

LoggerA (has concrete log)
  ^
  |
LoggerB (also has concrete log)
  ^
  |
Logged3

and override is necessary when overriding a concrete implementation.