Overloading Resolution + Vararg methods: example should be ambiguous #8344

scabug · 2014-02-26T12:11:59Z

Related to #4728. This compiles, the second alternative is chosen

object t {
  def f(x: Object) = 1
  def f(x: String*) = 2
}
t.f("") // returns 2, should be ambiguous.

According to #4728, it should be ambiguous. I assume the compiler thinks that String* conforms to Object. Maybe because it tests if Seq[String] conforms to Object, not sure.

The text was updated successfully, but these errors were encountered:

scabug · 2014-02-26T12:11:59Z

Imported From: https://issues.scala-lang.org/browse/SI-8344?orig=1
Reporter: @lrytz
Affected Versions: 2.11.0
See #4728

scabug · 2014-02-26T15:55:58Z

@som-snytt said:
I think #8342 will say that autotupling makes the first f applicable to arbitrary strings. There's an issue somewhere with the example with a type parameter.

scabug · 2014-02-26T16:03:25Z

@lrytz said:
Right, I forgot about that. Auto-tupling seems just wrong in too many situations.

scala> def f(x: Object) = 0
f: (x: Object)Int

scala> f(1,2,3)
res0: Int = 0

scabug · 2014-05-12T10:46:44Z

@som-snytt said:
Is this open because it's still unambiguous under -Yno-adapted-args? If that should matter? Asking for a friend.

apm@mara:~$ goof -Yno-adapted-args
Welcome to Scala version 2.11.0 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0).
Type in expressions to have them evaluated.
Type :help for more information.

scala> object t {
     |   def f(x: Object) = 1
     |   def f(x: String*) = 2
     | }
defined object t

scala> t.f("")
res0: Int = 2

scala> def g[A](a: A) = 7
g: [A](a: A)Int

scala> g(1,2,3)
<console>:9: warning: No automatic adaptation here: use explicit parentheses.
        signature: g[A](a: A): Int
  given arguments: 1, 2, 3
 after adaptation: g((1, 2, 3): (Int, Int, Int))
              g(1,2,3)
               ^
res1: Int = 7

adriaanm · 2019-01-25T10:34:07Z

Weird, I guess this should be ambiguous. You can't apply a String* to a method expecting an Object, and you can't supply an Object when expecting one or more String (note that, as a formal, the vararg is expanded, while it it's when an argument. -- see #7680).

adriaanm · 2019-01-25T10:40:42Z

While deciding which one is more specific, you get the following calls to isCompatibleArgs:

isCompatibleArgs false List(Object) <:< List(String)
isCompatibleArgs true List(String*) <:< List(Object)

the second one should be false too

We recntly merged scala#9601 which unified our handling of `Object` coming from Java methods, an unintended consequence of that change is that some existing Java APIs can no longer be called without running into ambiguity errors, for example log4j defines two overloads for `Logger.error`: (x: String, y: Object): Unit (x: String, y: Object*): Unit previously we translated `Object` to `Any` but left `Object*` alone, now they're both treated the same way (translated to a special alias of `Object`) and so neither method ends up being more specific than the other, so `error("foo: {}, 1)` is now ambiguous. Clearly the problem lies with how we handle varargs in overloading resolution, but this has been a source of issues for years with no clear resolution: - scala/bug#8342 - scala/bug#4728 - scala/bug#8344 - scala#6230 This PR cuts the Gordian knot by simply declaring that non-varargs methods are always more specific than varargs. This has several advantages: - It's an easy rule to remember - It matches what Java does (see https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2) - It avoids unnecessary wrapping of arguments The downside is that it doesn't match what Scala 2 does, but our current behavior isn't a perfect match either (also it seems that Scala 2 handles Java varargs and Scala varargs differently in overloading resolution which is another source of complexity best avoided, see `tests/run/overload_repeated`).

We recently merged scala#9601 which unified our handling of `Object` coming from Java methods, an unintended consequence of that change is that some existing Java APIs can no longer be called without running into ambiguity errors, for example log4j defines two overloads for `Logger.error`: (x: String, y: Object): Unit (x: String, y: Object*): Unit previously we translated `Object` to `Any` but left `Object*` alone, now they're both treated the same way (translated to a special alias of `Object`) and so neither method ends up being more specific than the other, so `error("foo: {}, 1)` is now ambiguous. Clearly the problem lies with how we handle varargs in overloading resolution, but this has been a source of issues for years with no clear resolution: - scala/bug#8342 - scala/bug#4728 - scala/bug#8344 - scala#6230 This PR cuts the Gordian knot by simply declaring that non-varargs methods are always more specific than varargs. This has several advantages: - It's an easy rule to remember - It matches what Java does (see https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2) - It avoids unnecessary wrapping of arguments The downside is that it doesn't match what Scala 2 does, but our current behavior isn't a perfect match either (also it seems that Scala 2 handles Java varargs and Scala varargs differently in overloading resolution which is another source of complexity best avoided, see `tests/run/overload_repeated`).

We recently merged scala#9601 which unified our handling of `Object` coming from Java methods, an unintended consequence of that change is that some existing Java APIs can no longer be called without running into ambiguity errors, for example log4j defines two overloads for `Logger.error`: (x: String, y: Object): Unit (x: String, y: Object*): Unit previously we translated `Object` to `Any` but left `Object*` alone, now they're both treated the same way (translated to a special alias of `Object`) and so neither method ends up being more specific than the other, so `error("foo: {}, 1)` is now ambiguous. Clearly the problem lies with how we handle varargs in overloading resolution, but this has been a source of issues for years with no clear resolution: - scala/bug#8342 - scala/bug#4728 - scala/bug#8344 - scala#6230 This PR cuts the Gordian knot by simply declaring that non-varargs methods are always more specific than varargs. This has several advantages: - It's an easy rule to remember - It matches what Java does (see https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2) - It avoids unnecessary wrapping of arguments The downside is that it doesn't match what Scala 2 does, but our current behavior isn't a perfect match either (also it seems that Scala 2 handles Java varargs and Scala varargs differently in overloading resolution which is another source of complexity best avoided, see `tests/run/overload_repeated`). Fixes scala#9688, supercedes scala#6230.

scabug added typer overloading labels Apr 7, 2017

scabug added this to the Backlog milestone Apr 7, 2017

scabug assigned lrytz Apr 7, 2017

scabug mentioned this issue Apr 7, 2017

Parenless overloaded methods are used in ambiguous cases #9395

Open

som-snytt mentioned this issue Jan 24, 2019

Align specificity of (a: T)... vs (a: T*)... with mono case scala/scala#7680

Merged

2 tasks

adriaanm mentioned this issue Jan 25, 2019

RepeatedParamType should not be a subtype of anything (until ElimRepeated) scala/scala3#5792

Closed

adriaanm closed this as completed in scala/scala#7680 Feb 4, 2019

adriaanm modified the milestones: Backlog, 2.13.0-RC1 Feb 4, 2019

SethTisue assigned adriaanm and unassigned lrytz Feb 4, 2019

scala deleted a comment from scabug Feb 4, 2019

abgruszecki mentioned this issue Apr 18, 2019

Fix #5792 scala/scala3#6230

Closed

som-snytt mentioned this issue Sep 2, 2020

Ambiguous overload between varargs and non-varargs scala/scala3#9688

Closed

smarter mentioned this issue Sep 3, 2020

Overloading: always prefer non-varargs to varargs scala/scala3#9718

Closed

som-snytt mentioned this issue Sep 5, 2020

Scalac confused which overload to pick when Java has multiple varargs overloads #8800

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Overloading Resolution + Vararg methods: example should be ambiguous #8344

Overloading Resolution + Vararg methods: example should be ambiguous #8344

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented May 12, 2014

adriaanm commented Jan 25, 2019 •

edited

adriaanm commented Jan 25, 2019

Overloading Resolution + Vararg methods: example should be ambiguous #8344

Overloading Resolution + Vararg methods: example should be ambiguous #8344

Comments

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented Feb 26, 2014

scabug commented May 12, 2014

adriaanm commented Jan 25, 2019 • edited

adriaanm commented Jan 25, 2019

adriaanm commented Jan 25, 2019 •

edited