Skip to content

Error Overriding: incompatible types #4771

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
allanrenucci opened this issue Jul 6, 2018 · 2 comments
Closed

Error Overriding: incompatible types #4771

allanrenucci opened this issue Jul 6, 2018 · 2 comments

Comments

@allanrenucci
Copy link
Contributor

sealed abstract class <:<[-From, +To] {
  def substituteCo[F[+_]](ff: F[From]): F[To]
}

sealed abstract class =:=[From, To] extends (From <:< To) {
  override def substituteCo[F[_]](ff: F[From]): F[To] = ???
}
dotc -d out tests/allan/Test.scala
-- Error: tests/allan/Test.scala:32:15 -----------------------------------------
32 |  override def substituteCo[F[_]](ff: F[From]): F[To] = ???
   |               ^
   |error overriding method substituteCo in class <:< of type [F <: [+_$1] => Any](ff: F[From]): F[To];
   |  method substituteCo of type [F <: [_$2] => Any](ff: F[From]): F[To] has incompatible type
one error found
@smarter
Copy link
Member

smarter commented Jul 6, 2018

With scalac, you can override a polymorphic def with another polymorphic def with less precise bounds:

class A {
  def foo[F <: Int] = {}
}
class B extends A {
  override def foo[F] = {}
}

I think this is OK from a soundness point of view since the variance checks out, but it's kind of inconsistent with the fact that we don't allow the same for term parameters, e.g. the following doesn't work with scalac:

class A {
  def foo(x: String) = {}
}
class B extends A {
  override def foo(x: Any) = {}
}

@smarter smarter self-assigned this Jul 6, 2018
@Blaisorblade
Copy link
Contributor

Blaisorblade commented Jul 6, 2018

I think this is OK from a soundness point of view since the variance checks out

Yes, it's just (like) contravariance of functions — I wonder if the second doesn't work just because of JVM restrictions?
Took me a second, but the "kind" of M[_] is also a "subkind" of the kind of M[+_], so the OP also checks out. No clue if/how the spec says that without kinds.

(Not that we have a soundness proof covering this contravariance, but just because we don't have a proof regarding higher-kinded types either).

smarter added a commit to dotty-staging/dotty that referenced this issue Jul 10, 2018
Just like in Scala 2, we now allow an override to widen the bounds of a
polymorphic type parameter (this is sound because parameters can vary
contravariantly). (And just like Scala 2, we continue not allowing an
overriding to widen the type of a term parameter).
smarter added a commit to dotty-staging/dotty that referenced this issue Jul 10, 2018
Just like in Scala 2, we now allow an override to widen the bounds of a
polymorphic type parameter (this is sound because parameters can vary
contravariantly). (And just like Scala 2, we continue not allowing an
overriding to widen the type of a term parameter).
smarter added a commit to dotty-staging/dotty that referenced this issue Jul 10, 2018
Just like in Scala 2, we now allow an override to widen the bounds of a
polymorphic type parameter (this is sound because parameters can vary
contravariantly). (And just like Scala 2, we continue not allowing an
overriding to widen the type of a term parameter).
smarter added a commit to dotty-staging/dotty that referenced this issue Jul 10, 2018
Just like in Scala 2, we now allow an override to widen the bounds of a
polymorphic type parameter (this is sound because parameters can vary
contravariantly). (And just like Scala 2, we continue not allowing an
overriding to widen the type of a term parameter).
smarter added a commit that referenced this issue Jul 10, 2018
Fix #4771: Relax overriding check for polymorphic methods
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants