Compat Scala 2: Abstract override

[allanrenucci]

class Seq

trait IterableOnceOps {
  def toSeq: Seq = new Seq
}

trait IterableOps extends IterableOnceOps

trait SeqOps extends IterableOps {
  def toSeq: Seq
}

class Foo extends SeqOps

The code snippet above compiles with Scala2 but not Dotty:

-- Error: tests/allan/Test.scala:53:6 ------------------------------------------
53 |class Foo extends SeqOps
   |      ^
   | class Foo needs to be abstract, since def toSeq: => Seq is not defined 
one error found

This pattern is used in the 2.13 collection library

[allanrenucci]

cc/ @julienrf

[allanrenucci]

Followup, If I do decide to implement toSeq in Foo, should I be required to add the override modifier:

class Foo extends SeqOps {
  def toSeq: Seq = new Seq
}

tests/allan/Test.scala:54: error: overriding method toSeq in trait IterableOnceOps of type => Seq;
 method toSeq needs `override` modifier
  def toSeq: Seq = new Seq
      ^
one error found

[Blaisorblade]

1. This seems to be specified as allowed (tho I'd clarify the spec), so I'm removing the Scala2 label — see member h in this example from https://www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#overriding:

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 }

Also, the text which defines overriding never forbids this scenario:

This definition also determines the overriding relationships between matching members of a class C and its parents. First, a concrete definition always overrides an abstract definition. Second, for definitions M and M' which are both concrete or both abstract, M overrides M′ if M appears in a class that precedes (in the linearization of C) the class in which M′ is defined.

2. Foo.toSeq overrides an existing implementation, so it seems override should be required as usual to ensure that the override is desired — luckily, that's even clear in the spec (https://www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#override).

https://www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#overriding

[Blaisorblade]

Apparently this is an intended change and matches Java semantics (though Martin didn't go into detail), so the spec should be updated and the compat:Scala2 label stays.

[smarter]

We should also see if we can make a rewrite rule for this.