Ambiguous implicit error involving implicits defined in the companions of classes where one is a subclass of another (works in Scala 2)

[dlwh]

or at least, it's changed from Scala 2.

First I want to say that Scala 3 is turning out to be a very nice language and I’m excited for what we can do with it. Thank you.

I am in the process of trying to get Breeze compiling under Scala 3. There is a common pattern in Breeze in how I organize implicits, where for a class XVector I have a trait XVectorOps with a bunch of implicits in it that object XVector extends. Usually these are stacked a bit. In Scala 2 this all worked fine, but in Scala 3, this leads to problems in the case where there is a subtype relationship between different XVectors.

Compiler version

3.0.0-RC2

Minimized code

This is a minimized example that compiles fine in Scala 2 but does not work in Scala 3:

trait Op[T, U]

trait HasOps[+This] {
  def foo[TT>:This, U](u: U)(implicit op: Op[TT, U]) = op
}

trait Vector extends HasOps[Vector]

class DenseVector extends Vector with HasOps[DenseVector]

trait VectorOps {
  implicit def vOp: Op[Vector, Double] = ???
}

object Vector extends VectorOps

trait DenseVectorOps {
  implicit def dvOp: Op[DenseVector, Double] = ???
}

object DenseVector extends DenseVectorOps

object Foo {
  def bar() = {
    val dv = new DenseVector
    dv.foo(3.0)
  }
}

Output

26 |    dv.foo(3.0)
   |               ^
   |ambiguous implicit arguments: both method dvOp in trait DenseVectorOps and method vOp in trait VectorOps match type Op[TT, Double] of parameter op of method foo in trait HasOps

Expectation

This compiles fine in Scala 2, and if I remove the XVectorOps classes and inline them into the companions directly this compiles fine in Scala 3, but the inheritance trips it up.

Is this intentional?

[dlwh]

I believe this is distinct from #12123 and #7999

[smarter]

It's fairly similar to #12123 actually, you're doing an implicit search on Op[TT, U]) where TT >: This, in the DenseVector case this will match both Op[Vector, Double] and Op[DenseVector, Double], and neither is more specific than the other. You can make the compiler prefer the Op defined in the subclass by making it covariant in its first type parameter:

trait Op[+T, U]

[dlwh]

Thanks @smarter. I can't do that because Op is actually more like

trait Op[T, U] {
  def apply(t: T, u: U)
}

In Scala 2, I think the preference for dvOp comes via the Relative Weighting rule. (6.26.3)

The relative weight of an alternative AAA over an alternative BBB is a number from 0 to 2, defined as the sum of

    1 if AAA is as specific as BBB, 0 otherwise, and
    1 if AAA is defined in a class or object which is derived from the class or object defining BBB, 0 otherwise.

A class or object CCC is derived from a class or object DDD if one of the following holds:

    CCC is a subclass of DDD, or
    CCC is a companion object of a class derived from DDD, or
    DDD is a companion object of a class from which CCC is derived.

An alternative AAA is more specific than an alternative BBB if the relative weight of AAA over BBB is greater than the relative weight of BBB over AAA.

https://scala-lang.org/files/archive/spec/2.13/06-expressions.html#overloading-resolution

Is that removed from Scala 3? I couldn't find the spec.

[dlwh]

(In fact, the reason I believe it different from 12123 is precisely this rule.) Note that it works fine if I remove the Ops traits, so I think that the definition of "defined in" is maybe change? I.e. this works fine, and it shouldn't by your logic?

trait Op[T, U]

trait HasOps[+This] {
  def foo[TT>:This, U](u: U)(implicit op: Op[TT, U]) = op
}

trait Vector extends HasOps[Vector]

class DenseVector extends Vector with HasOps[DenseVector]

object Vector {
  implicit def vOp: Op[Vector, Double] = ???
}

object DenseVector {
  implicit def dvOp: Op[DenseVector, Double] = ???
}

object Foo {
  def bar() = {
    val dv = new DenseVector
    dv.foo(3.0)
  }
}

[smarter]

Ah, you mean this rule in particular?

if AAA is defined in a class or object which is derived from the class or object defining BBB,

That rule still exists though it's been slightly modified, see point 6 of http://dotty.epfl.ch/docs/reference/changed-features/implicit-resolution.html

So maybe your original example should work indeed, dvOp and vOp are not declared in DenseVector and Vector, but they're clearly members of these classes. Reopening.

[dlwh]

Great thank you!

…

On Fri, Apr 16, 2021, 1:26 PM Guillaume Martres ***@***.***> wrote: Ah, you mean this rule in particular? if AAA is defined in a class or object which is derived from the class or object defining BBB, That rule still exists though it's been slightly modified, see point 6 of http://dotty.epfl.ch/docs/reference/changed-features/implicit-resolution.html So maybe your original example should work indeed, dvOp and vOp are not declared in DenseVector and Vector, but they're clearly members of these classes. Reopening. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACLIMMCCBBEE5X73X6MY3TJCMOFANCNFSM43CDQH5Q> .