Method in trait not a legal implementation in inheriting class

[allanrenucci]

trait Iterable[+A]

trait IterableOps[+A, +CC[_], +C] {
  def concat[B >: A](suffix: Iterable[B]): CC[B] = ???
}

trait SetOps[A, +CC[X], +C <: SetOps[A, CC, C]]  {
  def concat(that: Iterable[A]): C = ???
}

class ChampHashSet[A] extends SetOps[A, ChampHashSet, ChampHashSet[A]] with
    IterableOps[A, ChampHashSet, ChampHashSet[A]]

-- Error: tests/allan/Test.scala:15:6 ------------------------------------------
15 |class ChampHashSet[A] extends SetOps[A, ChampHashSet, ChampHashSet[A]] with
   |      ^
   |method concat in trait IterableOps is not a legal implementation of `concat' in class ChampHashSet
   |  its type             [B >: A](suffix: Iterable[B]): ChampHashSet[B]
   |  does not conform to  (that: Iterable[A]): ChampHashSet[A]
one error found

[Blaisorblade]

FWIW: I've taken a look and it makes sense to accept this (like Scalac does) — even ML-family languages allow implementations to be more polymorphic than interfaces.

[smarter]

@Blaisorblade Maybe, but the following has never been allowed in Scala:

trait Foo {
  def foo(x: String): Unit
}
class Bar extends Foo {
  def foo[B](x: String): Unit = {}
}

[smarter]

trait IterableOps[+A, +CC[_], +C] {
  def concat[B >: A](suffix: Iterable[B]): CC[B] = ???
}

ends up with a concat method whose erased type is:

def concat(suffix: Iterable): Object

whereas with:

trait SetOps[A, +CC[X], +C <: SetOps[A, CC, C]]  {
  def concat(that: Iterable[A]): C = ???
}

the erasure of concat is:

def concat(that: Iterable): SetOps

So in ChampHashSet we should be able to inherit from both of them and get two overloads for concat. This is what happens in scalac but in Dotty this is prevented by RefChecks for some reason.

[Blaisorblade]

Sorry I was too quick and hopeful and misunderstood this completely...

[allanrenucci]

cc/ @julienrf Is is intended to be an overload in the standard library?

Dotty was happy before scala/scala#6909 scala/scala#6776

[smarter]

Here's a minimization:

trait One[X]  {
  def concat(suffix: Int): X = ???
}

trait Two[Y <: Foo] {
  def concat[Dummy](suffix: Int): Y = ???
}

class Foo extends One[Foo] with Two[Foo]

Any attempt at simplifying this further (avoiding f-bounded polymorphism, removing the parameter lists from the methods, ...) compiles properly, so there's probably a subtle bug somewhere.

[julienrf]

@allanrenucci Yes, since Set is invariant its natural concat signature is without the B >: A type parameter.

[smarter]

The problem is in Denotation#&, when we try to merge the denotations of sym1 = Two#concat and sym2 = One#concat:
https://github.com/lampepfl/dotty/blob/89ab4990863da45d0862f0c69cb1d31235c4e1ac/compiler/src/dotty/tools/dotc/core/Denotations.scala#L528-L532
This calls infoMeet which will return the info of sym2 because it prefers MethodTypes over PolyTypes:
https://github.com/lampepfl/dotty/blob/89ab4990863da45d0862f0c69cb1d31235c4e1ac/compiler/src/dotty/tools/dotc/core/Denotations.scala#L394-L402
We then construct a JointRefDenotation using this info:
https://github.com/lampepfl/dotty/blob/89ab4990863da45d0862f0c69cb1d31235c4e1ac/compiler/src/dotty/tools/dotc/core/Denotations.scala#L545
But note that at this point, sym is the symbol of Two#concat (whose type is a PolyType) and jointInfo is the info of One#concat (whose type is a MethodType) so we're creating a very weird denotation. This then fails in RefChecks.

@odersky Does it really ever makes sense to merge a denotation with a MethodType and a denotation with a PolyType? Why not always return a MultiDenotation in these cases?