Ambiguously overloaded methods fail to error when assigned to a val

[jchyb]

Compiler version

main (97677cc), 3.3.0 and likely any previous version

Minimized code

def f(s: Int): Unit = println("a")
def f: Int => Unit = _ => println("b")

@main def Test =
  val test: Int => Unit = f
  test(0)
  // f(0) // this errors out as expected

Output

Compiles, and when run prints "a".

Expectation

Should error out with an Ambiguous Overload error, like using f directly does.

Additional comment

I found this when working on #18286, and I know that resolveOverloaded1 method here can affect which f is being chosen - so the issue likely lies somewhere there.

[iusildra]

I'll try to look at it, but I have a few questions:

Why should it produce an ambiguous overload error ? We want to assign to test an instance of Function1 and even though f(s: Int): Unit is a match, it requires a few transformations beforehand whereas f: Int => Unit can be taken as it is. In other words, it's a bit like the 2nd def is "more specific" than the 1st one. So I would expect it to print "b". Am I wrong ?

Also, if both "direct" & "indirect" calls must fail, shouldn't we instead prevent people from defining 2 methods where the second returns a FunctionN with the same arg types and return type than the first one ?

[som-snytt]

It's "b" in Scala 2.

I think this issue was previously discussed for Dotty, but I don't have a link or explanation handy.

(Maybe in Scala 2, overload resolution precedes eta expansion; that is, it's not an application, so first take alternatives that are compatible with the expected type; but the definition of compatible says after eta expansion, so that idea is not right.)

[dwijnand]

Why should it produce an ambiguous overload error ? We want to assign to test an instance of Function1 and even though f(s: Int): Unit is a match, it requires a few transformations beforehand whereas f: Int => Unit can be taken as it is. In other words, it's a bit like the 2nd def is "more specific" than the 1st one. So I would expect it to print "b". Am I wrong ?

It's a little ironic how your logical steps lead you to the other answer than what the compiler does - perhaps good evidence that it should be made to error as ambiguous. Not that we could afford to just flip the meaning from one version to the next anyways...

At a guess, the requirement of Int => Unit on test makes f be desugared to x => f(x), which the first def matches more readily. Btw, not only does the second def require an extra .apply, being a def means that it's an ExprType, i.e. => Int => Unit, which also might make it less readily applicable.

[iusildra]

It's a little ironic how your logical steps lead you to the other answer than what the compiler does - perhaps good evidence that it should be made to error as ambiguous.

Seems legit 😆

[som-snytt]

Should error out with an Ambiguous Overload error, like using f directly does.

This is a "direct use" of f:

val test: Int => Unit = f

Spec says:

Implicit conversions can be applied to expressions whose type does not match their expected type, to qualifiers in selections, and to unapplied methods.

None of those conditions apply. Odersky is firm in the linked PR that the behavior is "as specified". Maybe these are the spec words which mean "do the obvious thing and take f since it works."

[som-snytt]

Duplicates #4831

Dotty came around and agrees with Scala 2 since [checks watch] 3.3.4.

➜  snips scala-cli run --server=false -S 3.5.2 i18294.scala
b
➜  snips scala-cli run --server=false -S 3.3.4 i18294.scala
b
➜  snips scala-cli run --server=false -S 3.3.3 i18294.scala
a

I see this behavior progressed in the linked PR for 3.4.1 then backported to LTS.