-
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
Match type regression #18448
Comments
@sjrd I would love your comment on this, considering I used this match types trick for the lack of |
These are all fully-defined match types (without type captures), so there's no reason they shouldn't work. That said, I think your type <:![T <: UB, UB] <: UB = T & UB |
Oh, yeah, thanks! I think it's the third time I'm forgetting |
Do you mean type <:![T <: UB, UB] = T & UB ? |
Again, lack of GADT constraints during phases that aren't Typer...
is simplifying to T, while it should actually be simplifying to |
Yes, that's what he meant and it works. |
Ah, yes, I missed that the definition requires some GADT-style reasoning. There's not supposed to be GADT reasoning in match types. How come that definition then compiles in the separate compilation situation. It shouldn't there either. 🤨 And yes, that means relying on it was already relying on a bug. Not just relying on the current unspecified match type reduction. |
Ok, in this case a bug was fixed (the multi-module code should not compile) and this issue needs to be resolved as a neg test. |
I don't see why GADT reasoning, or, rather, subtype reconstruction, shouldn't apply for match types. |
To minimise: trait Foo
type MT[A] <: Foo = A match
case Foo => A should compile, rather than
|
You would need to write a spec for exactly what subtype reconstruction does in every possible situation and with the exact outcome, and then never change it anymore, if you want to apply it to match types. |
We don't have that for term match trees, so why is it necessary for match type trees? |
For term match trees, whatever the type checker comes up with is then persisted in TASTy in the form of synthetic |
Then I guess we could cop out some more of doing any spec-ing with some type level synthetic casting types.
type <:![T <: UB, UB] <: UB = T match
case UB => T
|
Nvm, it is bounds checking, but not here, in the other match type. In that match type, trait Foo
type Of[T] <: Foo = T match
case Foo => T <:! Foo
|
OK, I'm not clear what is supposed to happen here, and if this is a bug that I accidentally treated as a feature or it's supposed to work. Under 3.3.0 (LTS) this code compiles successfully, BUT I just noticed that if everything is in the same file and not across modules, then it does not.
Compiler version
Last good release: 3.4.0-RC1-bin-20230818-932c10d-NIGHTLY
First bad release: 3.4.0-RC1-bin-20230821-6e370a9-NIGHTLY
First bad commit: 34dbdd8
Regression from #18398
Minimized code
UBMatch.scala
UBMatch.test.scala
Output
Expectation
Should compile (not completely sure, see comment on the head of the issue)
Edit: Should not compile (see discussion)
The text was updated successfully, but these errors were encountered: