-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Unsound type propagation/refinement *without case classes* #4014
Comments
Fixed title, the |
Debugging, see the following logs:
|
Thanks for taking a look! So this is a close variant of https://github.com/lampepfl/dotty/pull/4013/files/7ae7560a70acb2715e102af08329ec7cb0c9c1a1..49f9dc6bf0567f4d429ec85777355429f2a6cbaa#diff-67f55293f2001c7ef140f0932e65023e, so I'm hoping that PR will fix this example as well. (EDIT: not yet done). |
Compiling this on fix-#3989 I get: -- [E007] Type Mismatch Error: i4014.scala:7:24 -------------------------------- So it seems this is already covered. |
Due to @odersky — he generalized the first part of #3989 without using case classes.
I reconstructed the example from its core (
case b: B[_] => a.i
), but that was tricky, hence this ticket.Transcript:
The basic strategy is similar to #3989 (comment), but it's a bit trickier to exploit it. The compiler assumes that
a: A[Int]
is also aB[Int]
while it can be, in fact,B[String]
— or in general, it can be aB[X]
for arbitraryX
.Since here no case classes are involved, we can't forbid definitions like
C
(they're too common), @odersky suggested that we simply deducing unsound constraints aboutX
.Conversely, for GADTs we can make the opposite tradeoff: forbid definitions like
C
and allow deducing (sound) constraints on type variables as usual.I'm a bit concerned by the irregularity, but it's hard to think of anything better.
The text was updated successfully, but these errors were encountered: