Implicit resolution fails for overloaded method with type parameter

Dotty seems to have inherited this issue from Scala: https://github.com/scala/bug/issues/9523

object works {
  class A {
    def foo(): String = ???
  }
  implicit class PimpedA(a: A) {
    def foo(i: String): String = ???
  }
  val a = new A()
  a.foo("test") //compiles
}

object fails { //same as `works`, but adds type parameter
  class A {
    def foo[T](): String = ???
  }
  implicit class PimpedA(a: A) {
    def foo[T](i: String): String = ???
  }
  val a = new A()
  PimpedA(a).foo("test") // compiles
  a.foo("test") // error: too many arguments for method foo: (): String
}

[odersky]

The attempted fix in scalac is still not merged.

The best summary is from @adriaanm’ on scala/scala#7396:

The spec says:

In a selection e.m(args) with e of type T, if the selector m denotes some member(s) of T, but none of these members is applicable to the arguments args.

In this case a view v is searched which is applicable to e and whose result contains a method m which is applicable to args. The search proceeds as in the case of implicit parameters, where the implicit scope is the one of T. If such a view is found, the selection e.m is converted to v(e).m(args).

The problem was that the failing selection would actually look like e.m[T], where we need to strip the [T] so that the adapted expression v(e).m’ can infer the appropriate type params (most likely different from [T]).

So, one can argue that the compiler and the spec actually agree: It’s not a selection e.m(args) but a selection e.m[T](args). Of course the [T] is inserted by type inference, so this now depends on the way rules in the spec are ordered.

To fix this on the typer side would be very messy, I fear. This is also born out by the fact that the attepted fix in scalac did not make it in so far. So I prefer to declare the status quo as law and fix it on the spec side.

[smarter]

Fixed by https://github.com/lampepfl/dotty/pull/12719