Implicit resolution fails for overloaded method with type parameter

[Jasper-M]

Dotty seems to have inherited this issue from Scala: scala/bug#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
}

[SethTisue]

@odersky this is the bug that @adriaanm and @szeiger were telling you about today

[smarter]

Fix in scalac for the same bug: scala/scala#7396

[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.

[mdedetrich]

I understand that the fix is messy but this also appears like a massive oversight from a language usage perspective, it seems completely arbitrary that extension methods work without type parameters but fail with them.

Also if the spec is unclear when it comes to ordering then we should try and fix the spec so it is clear rather than trying to use the current ambiguity as a justification to not fix an issue because its inconvenient to do so.

[smarter]

Fixed by #12719