Pattern match on GADT not recognizing case as impossible (regression from Scala 2)
See original GitHub issueI tried searching around to see if this was a duplicate issue. I found a lot of issues around GADTs and pattern matching but didn’t think the code in any of them were as simple as in this one. I hope this is not a duplicate.
Compiler version
3.0.0
Minimized code
Written with Scala 2 syntax for easy 🍎 to 🍏 comparison:
sealed trait Foo[A]
final case class Bar(value: String) extends Foo[String]
object Example {
def whatthe[A, B]: Foo[A => B] => Unit = {
case Bar(_) => ()
}
}
Result
The compilation succeeds in Scala 3.
Expectation
A compilation error similar to the one that I get if I try to compile the same code in Scala 2.13.6:
error: constructor cannot be instantiated to expected type; found : Bar required: Foo[A => B]
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:10 (10 by maintainers)
Top Results From Across the Web
Type inference error while pattern matching - scala
In the below code I keep getting this error — pattern type is incompatible with expected type; Which I feel is incorrect.
Read more >pattern matching over covariant GADT unsound #8563 - GitHub
The following code produces a ClassCastException at runtime: object Test extends App { sealed trait Node[+A] case class L[C,D](f: C => D) extends...
Read more >Changelog for Agda-2.6.0.1 - Hackage - Haskell.org
Absurd clauses are still required in case deep pattern matching is needed to expose the absurd variable, or if there are no non-absurd...
Read more >Eirik Tsarpalis' blog – Notes in Programming & Mathematics
object json string encoder used for union case payloads ... This pattern is not strictly applicable to event serialization. ... match ta with....
Read more >DAML SDK Documentation
be no account number. To do this, you can use pattern matching and either throw errors or return compatible types for all cases:....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
SLS 8.5 states unambiguously that the pattern matching anonymous function desugars as follows:
Scala 2 and Scala 3 are both consistent about handling the sugary and desugared versions the same (Scala 2 same error in both cases, Scala 3 no error in both cases). So we can disregard the pattern-matching-anonymous-function aspect of this and deal directly with the raw pattern match.
We can also minimize it further to just:
again, Scala 2 gives a type error, Scala 3 accepts it.
And note that Scala 2 isn’t only rejecting the code because there’s a single case. It still rejects it even if you put a catchall case in:
That Scala 2 error isn’t an exhaustivity error, it’s a typer error, because the match doesn’t type. And I think it’s right (or, rather, I can’t think why Scala 3 thinks that’s wrong), so I think the fix is in typing the case.