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

Change in behavior in 2.13 for implicit overloads #11662

Open
travisbrown opened this issue Aug 5, 2019 · 4 comments

Comments

@travisbrown
Copy link

commented Aug 5, 2019

This code compiles on Scala 2.10, 2.11, and 2.12:

class Foo(xs: List[_])
object Foo {
  def make(xs: List[_]): Foo = new Foo(xs)
  implicit def make[A](xs: List[A])(implicit X: DummyImplicit): Foo = new Foo(xs)
}

List(""): Foo

…but the last line fails to compile on 2.13.0:

scala> List(""): Foo
           ^
       error: ambiguous reference to overloaded definition,
       both method make in object Foo of type [A](xs: List[A])(implicit X: DummyImplicit)Foo
       and  method make in object Foo of type (xs: List[_])Foo
       match argument types (List[String]) and expected result type Foo

I'm about 80% convinced the bug is on the 2.10, 2.11, 2.12 side of things, and that the 2.13.0 behavior is correct, but I'm opening this issue for the 20% where I'm wrong about that.

For what it's worth I ran into this issue in real code in the Sangria tests.

@smarter

This comment has been minimized.

Copy link

commented Aug 5, 2019

I'd say it's a bug, it seems like the compiler is attempting to do overload resolution after having selected an implicit which doesn't make sense

@travisbrown

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

@smarter Do you mean it's a bug that it compiles on 2.12, etc., or that it fails on 2.13? In general I'd expect this kind of thing to fail—e.g. the following example does on all Scala versions I've tried:

class Foo(x: Int)
object Foo {
  def make(x: Int): Foo = new Foo(x)
  implicit def make(x: Int)(implicit X: DummyImplicit): Foo = new Foo(x)
}

val foo: Foo = 1
@smarter

This comment has been minimized.

Copy link

commented Aug 5, 2019

Do you mean it's a bug that it compiles on 2.12, etc., or that it fails on 2.13?

I meant that it should work on 2.13, because it shouldn't do overloading resolution after it's found what implicit to call.

In general I'd expect this kind of thing to fail—e.g. the following example does on all Scala versions I've tried:

It works on Dotty, as does your original example :).

@hrhino hrhino added the regression label Aug 5, 2019

@hrhino hrhino changed the title Change in behavior in 2.13 for implicit overrides Change in behavior in 2.13 for implicit overloads Aug 5, 2019

@som-snytt

This comment has been minimized.

Copy link

commented Aug 7, 2019

FWIW, the behavior changed in M5. With debug turned up, it does in fact type check Foo.make(list), but in the success case it infers A and prefers that method. In M5, it can no longer choose and correctly sees them as ambiguous. There were a few changes in existentials and implicits in M5. It's almost Labor Day, a long enough weekend to ponder such matters during the usual recreations afforded by the nominal end of summer. But as smarter said, it should only be looking at eligible implicits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.