Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overloading resolution #5729

Closed
scabug opened this issue May 1, 2012 · 10 comments
Closed

overloading resolution #5729

scabug opened this issue May 1, 2012 · 10 comments

Comments

@scabug
Copy link

scabug commented May 1, 2012

Compiled in -M2, not presently.

object C {
  def join(in: Seq[List[_]]): Int = error("TODO")
  def join[S](in: Seq[List[S]]): String = error("TODO")

  join(Seq[List[Int]]())
  // 
  // ./a.scala:13: error: ambiguous reference to overloaded definition,
  // both method join in object C of type [S](in: Seq[List[S]])String
  // and  method join in object C of type (in: Seq[List[_]])Int
  // match argument types (Seq[List[Int]])
  //   join(Seq[List[Int]]())
  //   ^
  // one error found
}
@scabug
Copy link
Author

scabug commented May 1, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5729?orig=1
Reporter: @paulp
Other Milestones: 2.10.0

@scabug
Copy link
Author

scabug commented May 2, 2012

@adriaanm said:
fixed by adriaanm/scala@3e20beb

@scabug
Copy link
Author

scabug commented Nov 28, 2016

@milessabin said:
Looking closely at 6.26.3 and the implementation of isAsSpecificAs I believe that it is correct to report an ambiguity in this case: the spec provides no justification for preferring the polymorphic join[S] over the monomorphic (albeit existential) join.

@scabug
Copy link
Author

scabug commented Nov 29, 2016

@milessabin said:
It seems that Dotty agrees that this should be ambiguous.

@scabug
Copy link
Author

scabug commented Dec 1, 2016

@adriaanm said:
Miles convinced me this should be ambiguous. See scala/scala#5376

@scabug
Copy link
Author

scabug commented Dec 2, 2016

@lrytz said:
reverted in scala/scala#5573

@scabug
Copy link
Author

scabug commented Dec 2, 2016

@milessabin said:
I'm not seeing the justification for reopening this. The behaviour is in line with the spec.

@scabug
Copy link
Author

scabug commented Dec 3, 2016

@adriaanm said:
But it's not fixed since I had to revert my type inference hack that somehow made this work

@scabug
Copy link
Author

scabug commented Dec 3, 2016

@milessabin said:
Understood, but the description is misleading now that we've established that ambiguity is the correct result.

@scabug scabug added this to the 2.10.0-M3 milestone Apr 7, 2017
@milessabin milessabin modified the milestones: 2.10.0-M3, 2.13.0-M4 Mar 9, 2018
@lrytz lrytz removed this from the 2.13.0-M4 milestone Apr 19, 2018
@adriaanm adriaanm removed their assignment Sep 28, 2018
@som-snytt
Copy link

som-snytt commented Jan 24, 2019

Confirming that dotty still agrees with milesy:

scala> object exist { def join(in: Seq[List[_]]): Int = 1
     | def join[S](in: Seq[List[S]]): String = "42" }
// defined object exist

scala> exist.join(Seq[List[Int]]())
1 |exist.join(Seq[List[Int]]())
  |^^^^^^^^^^
  |Ambiguous overload. The overloaded alternatives of method join in object exist with types
  | [S](in: Seq[List[S]]): String
  | (in: Seq[List[_]]): Int
  |both match arguments (Seq[List[Int]])

Some of these stale threads with multiple inversions are a challenge to follow. This one falls under "not a bug" (which turns out not to be a label) as opposed to spec change or enhancement or fixed in dotty. Also there is no more to do, the previous change was reverted that day, that cold, cold day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants