Implicit resolution fails for overloaded method with type parameter

[scabug]

The first example successfully finds the implicit conversion to the method foo(String), however as soon as I add a type parameter (see fails) the compiles doesn't resolve it anymore. Note that my goal is to overload the method foo - if i rename it, the compiler finds it.

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
}

I asked this question already here: http://stackoverflow.com/questions/33162618/why-does-scala-implicit-resolution-fail-for-overloaded-method-with-type-paramete
and got this helpful answer from Alexey Romanov:

Both cases seem to fall under this case of the specification
http://www.scala-lang.org/files/archive/spec/2.11/07-implicit-parameters-and-views.html#views

Views are applied in three situations:
...
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).

So it should work.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9523?orig=1
Reporter: Michael Pollmeier (pollmeier)
Affected Versions: 2.11.7, 2.12.0-M3

[scabug]

Michael Pollmeier (pollmeier) said:
Typer debug output

[Jasper-M]

Another example I think: http://stackoverflow.com/questions/43402995/implicit-conversion-is-not-applied-if-generics-are-present

implicit def CToC2(obj: C1): C2 = {
  new C2()
}

class C1() {
  def f[U](i: Int): Unit = ???
}

class C2() {
  def f(s: String): Unit = ???
}

val c1 = new C1()
c1.f("a")    // error: type mismatch; found: String("a") required: Int

Remove type parameter U and it works.

---

Or

val zip = (List(1, 3, 5), List(2, 4, 6)).zipped
val f: ((Int, Int)) => Unit = x => println(x._1 + x._2)
zip.foreach(f)

which should work, since the std lib contains a conversion for this purpose: https://github.com/scala/scala/blob/v2.12.1/src/library/scala/runtime/Tuple2Zipped.scala#L31

[SethTisue]

#11232 is a recent duplicate. PR with fix: scala/scala#7396

[adriaanm]

I won't have time to get this fix over the finish line for RC1. Tentatively scheduled for 2.13.1, but it may have to be 2.14 if it turns out too breaking of a change.

[sageserpent-open]

This has cropped up in a slightly different form for me too: https://users.scala-lang.org/t/error-in-method-resolution-between-core-method-and-pseudo-overload-in-syntax-helper/7102 .

In this case, the type parameter on the method provided by the syntax enhancement is used in the argument signature, but still fails to unify with the actual argument.

To make matters more interesting, the same problem happens in reverse if the method in the core class has the type parameter and the one in the syntax enhancement doesn't. Again, this occurs even if the core class's method actually uses the type parameter in the argument signature.