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

Overload resolution doesn't use provided type parameters #11015

Closed
joroKr21 opened this issue Jan 6, 2021 · 1 comment · Fixed by #11080
Closed

Overload resolution doesn't use provided type parameters #11015

joroKr21 opened this issue Jan 6, 2021 · 1 comment · Fixed by #11080
Assignees
Milestone

Comments

@joroKr21
Copy link
Member

joroKr21 commented Jan 6, 2021

Reporting this as a bug because I would argue it's about Scala 2 compatibility.

Minimized code

import annotation.targetName

object Foo {
  def apply[A <: Int]: Int = 0
  @targetName("applyS") def apply[B <: String]: String = "0"
}

Foo[Int]

Output

scala> import annotation.targetName
     |
     | object Foo {
     |   def apply[A <: Int]: Int = 0
     |   @targetName("applyS") def apply[B <: String]: String = "0"
     | }
     |
     | Foo[Int]
8 |Foo[Int]
  |^^^
  |Ambiguous overload. The overloaded alternatives of method apply in object Foo with types
  | [B <: String] => String
  | [A <: Int] => Int
  |both match type arguments [Int] and expected type <?>

Expectation

I would expect that to work.
Recently we merged a PR in Scala 2 that fixed it for HKTs: scala/scala#9405
Note that this worked in Scala 2 way before my PR (which is just the natural extension to HKTs):

scala> object Foo {
     |   def apply[A <: Int]: Int = 0
     |   def apply[B <: String](implicit dummy: DummyImplicit): String = "0"
     | }
object Foo

scala> Foo[Int]
val res5: Int = 0

scala> Foo[String]
val res6: String = 0

If this change is intentional maybe it should be documented in overload-resolution.md

@odersky
Copy link
Contributor

odersky commented Jan 7, 2021

I agree it should work. The problem is that bounds-checking is not part of applicability (it is checked later to avoid cycles), so overloading resolution ignores it.

@odersky odersky self-assigned this Jan 7, 2021
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 12, 2021
When resolving overloaded polymorphic variants with explicit type
arguments, discard those variants where the given argument does not
fit the type parameter bounds.

Fixes scala#11015
@Kordyjan Kordyjan added this to the 3.0.0 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants