-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Union matching not exhaustive or refining #5970
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
Comments
I agree that the uncheckable warning in the last example is spurious, and should be fixed. For the warnings & type checking errors in the first two examples, I am not so sure, giving the possibility of the following program: object Test extends App {
case class Foo[T](t: T)
def foo[T](ft: T|Foo[T]): T = {
ft match {
case Foo(t: T) => t
case t: T => t
}
}
foo[Foo[Int]](Foo(23))
} |
Good point. Is there a way of capturing this idea without unsafe casts? |
@milessabin It seems to me the safe way is the standard sum types: object Test extends App {
case class Foo[T](t: T)
def foo[T](ft: Either[T, Foo[T]]): T = {
ft match {
case Left(t) => t
case Right(Foo(t)) => t
}
}
foo(Left(Foo(23)))
} (Typecase + union types + type parameters + erasure semantics) creates complexity. |
Unfortunately the aim was to avoid boxing in the common, ie. non- |
cf. #5826
there is no way to achieve that because there is no way to prevent You could make So you'll have to go with a similar approach to Sebastian's unboxed options (call it |
Fix #5970: suppress spurious warning in isInstanceOf check
Compiling the following,
results in,
Intuitively the pattern matcher ought to be able to see that the
t
's on the RHS's of the branches conform toT
. If we add type tests,The match is reported as not exhaustive and the type tests are reported as uncheckable, despite being intuitively irrefutable.
Replacing the
T
in the union withUnit
eliminates the non-exhaustiveness, but still results in a complaint about uncheckability,The text was updated successfully, but these errors were encountered: