Ambiguous overload: false detection

[satorg]

Compiler version

Scala 3.2.1

Minimized code

case class Foo[A](a: A) {
  def bar(aa: A): Boolean = a == aa
  def bar(that: Foo[A]) = a == that.a
}

object Test {
  Foo(123).bar(Foo(456))
}

Output

The snippet compiles just fine on 2.12.17 and 2.13.9, but fails to compile on 3.2.1 with the following error:

7 |  Foo(123).bar(Foo(456))
  |  ^^^^^^^^^^^^
  |Ambiguous overload. The overloaded alternatives of method bar in class Foo with types
  | (that: Foo[A]): Boolean
  | (aa: A): Boolean
  |both match arguments (Foo[A])

However, if I change the Test object this way:

object Test {
  val foo123 = Foo(123)
  foo123.bar(Foo(456))
}

then it compiles on 3.2.1 without any error as well.

Expectation

Both cases should compile on 3.2.1.

Notes

May be similar to #14582 and #16067.

[prolativ]

I looks like the compiler tries to defer the inference of the type parameter of the first Foo and it's yet not inferred when the compiler tries to resolve the overload. The snippet starts to compile if you pass this type explicitly

case class Foo[A](a: A) {
  def bar(aa: A): Boolean = a == aa
  def bar(that: Foo[A]) = a == that.a
}

object Test {
  Foo[Int](123).bar(Foo(456))
  Foo[Any](123).bar(Foo(456))
}

[yzia2000]

Is this a bug or an intended effect?

[prolativ]

For me the current behaviour of the compiler is rather unexpected and misleading so I would classify this as a bug.
But I cannot say for sure that this delay in type inference was an unintended - maybe there was some corner case when this was helpful but no specific example comes to my mind right now.
However we might try to fix this anyway to make the initial snippet work or at least make the error message clearer

[odersky]

The delay in instantiation is intended. It's one of the reasons Scala 3 generally infers better than Scala 2 (i.e. we are a couple of steps closer to global type inference). But in this case it has negative consequences.

[dwijnand]

I haven't run the compiler through this, but running my brain through it, I think the only enhancement we could consider is adding a filter on the overloads consider by considering that A <: Int & Foo[...] is uninhabited and thus the overload should be discarded and the remaining one picked. But we would also have to consider null, which could inhabit Int & Foo[...]. And also that would only be true in this case because Int is final.

[odersky]

I haven't run the compiler through this, but running my brain through it, I think the only enhancement we could consider is adding a filter on the overloads consider by considering that A <: Int & Foo[...] is uninhabited and thus the overload should be discarded and the remaining one picked. But we would also have to consider null, which could inhabit Int & Foo[...]. And also that would only be true in this case because Int is final.

I don't think that the added complexity would justify the gains.