position of using clause prevents overloaded extension method being picked

[rjolly]

Compiler version

3.0.0-RC1

Minimized code and output

extension [T1](x: T1)(using Numeric[T1])
  def combine[T2](y: T2)(using Numeric[T2]) = ???
  def combine(y: String) = ???

val res = 100.combine(200)
//        ^^^^^^^^^^^
//    value combine is not a member of Int.
//    An extension method was tried, but could not be fully constructed:
//
//        combine()    failed with
//
//            value combine: <overloaded combine> does not take parameters

Expectation : should work, as when we move using to the end of the parameter list:

extension [T1](x: T1)
  def combine[T2](y: T2)(using Numeric[T2], Numeric[T1]) = ???
  def combine(y: String) = ???

val res = 100.combine(200)

[odersky]

That will be quite hard to do. Overloading resolution is super hard as it is. This would make it worse.

[rjolly]

Is its interaction with implicit resolution documented somewhere?

[rjolly]

What's disturbing is that with non-extensions it succeeds:

def combine[T1,T2](x: T1)(using Numeric[T1])(y: T2)(using Numeric[T2]) = ???
def combine[T1](x: T1)(using Numeric[T1])(y: String) = ???

val res = combine(100)(200)

So it seems we're not far from the goal.

[rjolly]

Answering to myself : https://dotty.epfl.ch/docs/reference/changed-features/implicit-resolution.html

7. The rule for picking a most specific alternative among a set of overloaded or implicit alternatives is refined to take context parameters into account. All else being equal, an alternative that takes some context parameters is taken to be less specific than an alternative that takes none. If both alternatives take context parameters, we try to choose between them as if they were methods with regular parameters. The following paragraph in the SLS §6.26.3 is affected by this change:

Original version:

An alternative A is more specific than an alternative B if the relative weight of A over B is greater than the relative weight of B over A.

Modified version:

An alternative A is more specific than an alternative B if

the relative weight of A over B is greater than the relative weight of B over A, or
the relative weights are the same, and A takes no implicit parameters but B does, or
the relative weights are the same, both A and B take implicit parameters, and A is more specific than B if all implicit parameters in either alternative are replaced by regular parameters.

It says nothing about the position of argument lists, probably because it predates multiple implicit argument lists, and the fact that these had to be at the end(?)

[YourPsychiatrist]

I think I found a similar occurrence:

extension [T1] (x: T1)
  def f(fn: T1 ?=> Unit) =
    fn(using x)
  def f(s: String) = 
    s

// just yields "Hello"
val a = 100.f("Hello")

// error, 100.f() was considered yada yada
val res = 100.f { 
  println("wat")
}

I am guessing that is because A ?=> B compiles to A => B with using clause attached, but that's really just a wild guess. Would love to look into it, though. Of course, only in case the consensus is that the current state is not intended behaviour and overload resolution should pick the correct (the intended, that is) function.

[som-snytt]

Also extension with overload, using: #13668