-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Matching against a recursive type (RecType
) is unsound
#11097
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
The compiler needs to issue unchecked warning & unreachable case here as it is done for non-recursive refinement types. |
It seems that something similar happens for type refinement: trait S[A]
trait P[A] extends S[A]
def pmatch[A](s: S[A]): A = s match {
case p: P[_ >: Int] =>
10
}
// ClassCastException: class java.lang.Integer cannot be cast to class java.lang.Boolean
val x = pmatch(new P[Boolean]{}) |
Thanks @mario-bucev , an unchecked warning is indeed missing for the 2nd example as well. The following code class C { type T1; type T2 }
def pmatch(s: C) = s match {
case p: (C { type T1 = Int }) =>
case p: (C { type T1 = String }) =>
} gets the expected warning: -- [E030] Match case Unreachable Warning: examples/patmat.scala:5:7 ------------
5 | case p: (C { type T1 = String }) =>
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Unreachable case
-- Warning: examples/patmat.scala:4:7 ------------------------------------------
4 | case p: (C { type T1 = Int }) =>
| ^^^^^^^^^^^^^^^^^^^^^^^^
| the type test for C{T1 = Int} cannot be checked at runtime
2 warnings found |
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 8, 2022
michelou
pushed a commit
to michelou/scala3
that referenced
this issue
Apr 25, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Minimized code
Output
Click to expand
Expectation
We could expect the second branch to be matched, but due to erasure, I do not think it is possible.
I believe issuing a warning specifying that such a runtime check cannot be performed could be a consideration. I also think that
(3: p.T1): p.T2
should be rejected since we cannot be certain that we have{ type T1 = Int; type T2 >: T1 }
(similarly for the second match branch).The text was updated successfully, but these errors were encountered: