Skip to content

Overload resolution fails for existential #8955

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

Closed
martijnhoekstra opened this issue May 11, 2020 · 0 comments · Fixed by #11673
Closed

Overload resolution fails for existential #8955

martijnhoekstra opened this issue May 11, 2020 · 0 comments · Fixed by #11673
Assignees
Milestone

Comments

@martijnhoekstra
Copy link
Contributor

Minimized code

class One[A]{}
def test[A](a: Class[A]) = println(a)
def test[A](as: List[A]) = println(as)
def tost[A](a: Class[A]) = println(a)

@main def main() = {
  val one: One[_] = new One()
  test(one.getClass()) //this fails
  val cls = one.getClass()
  test(cls) //this is ok
  tost(one.getClass()) //this is also ok
}

Output

None of the overloaded alternatives of method test with types
 [A](as: List[A]): Unit
 [A](a: Class[A]): Unit
match arguments (Class[? <: One[?]])

Expectation

of

test(one.getClass())
test(cls)
tost(one.getClass())

either all of them compile, or all of them fail. They all compile in scala 2.

@odersky odersky self-assigned this Jan 6, 2021
odersky added a commit to dotty-staging/dotty that referenced this issue Mar 9, 2021
Fixes scala#8955

This kicks in if an argument is of wildcard type, say, C[?},
and one or more alternatives have a poymorphic method type
with type parameter `T` and corresponding parameter type
`C[T]`. We did wildcard capture for regular applicatiins, but
not for applicability testing of overloaded alternatives.
@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