-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Const
type inference glitch
#1608
Comments
FWIW, this works: object Foo {
type MyNothing >: Nothing <: Nothing
}
case class Const[A, B >: Foo.MyNothing](a: A)
object Test {
def trav[F[_], A, B](f: A => F[B]): F[B] = ???
val c: Const[Int, Int] = trav(Const(_:Int)) //compiles
val a: Int = trav(Const(_:Int)).a //compiles too!
} (The original example also compiles with dotty which does not suffer from nilophobia) |
To me, this is not such a big deal. There are many areas where scala's type inference is not great. In such cases, you sometimes have to use type parameters (or in case matching, even introduce methods for the sole purpose of naming all the type parameters on the matched class, especially in cases with variance). This seems to me like a case of "don't do that". Certainly making Const covariant seems like the cure being worse than the disease. |
Const
's phantom type can cause some type inference difficulty in scalac. Here is a minimized example:Making the phantom type covariant will helped the type inference but it's not a very obviously sound solution. See the discussion here by @ceedubs , here by @djspiewak and here by @johnynek.
Shall we live with the type inference inconvenience (not encountered very often though) or the possible ramifications of unnecessarily making the phantom type covariant?
It seems to me that neither incurs significant cost to pay but the former solution is easier to understand.
The text was updated successfully, but these errors were encountered: