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
check exhaustivity involving user-defined extractors with precise return type #4691
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4691?orig=1 |
@Sciss said: object Order {
sealed trait EntryOption
case object EmptyEntry extends EntryOption
trait Entry extends EntryOption
// this doesn't emit a warning:
def isEmpty( a: EntryOption ) : Boolean = a match {
case EmptyEntry => true
// case _: Entry => false
}
} |
@Sciss said: trait Order {
sealed trait EntryOption
case object EmptyEntry extends EntryOption
sealed trait Entry extends EntryOption
private final class EntryImpl extends Entry
def isEmpty( a: EntryOption ) : Boolean = a match {
case EmptyEntry => true
// case _: Entry => false
}
} This code above does emit the warning. But the following variation not: trait Order {
sealed trait EntryOption
case object EmptyEntry extends EntryOption
sealed trait Entry extends EntryOption
def isEmpty( a: EntryOption ) : Boolean = a match {
case EmptyEntry => true
// case _: Entry => false
}
}
trait OrderImpl extends Order {
private final class EntryImpl extends Entry
} |
@adriaanm said: |
Arseniy Alekseyev (rotsor) said (edited on Jun 11, 2012 2:33:43 PM UTC): Anyway, the warnings need to become conservative to be useful. Let's wait for that to happen first. |
I think you misunderstood what Adriaan said. You said that user-defined extractors are total, but Scala does not and cannot check that (for the general case anyway -- it's theoretically possible to detect trivial cases). Since it can never decide whether a pattern with user-defined extractors is exhaustive or not, it simply turns that feature off, therefore not warning in cases where it could make a statement to the effect that the matching is definitely not exhaustive. Anyway, given that the pattern matcher cannot warn non-exhaustiveness correctly, it doing so in some cases might lead people to think that absence of a warning as an assertion of exhaustiveness (which it is not). |
@adriaanm said: Also, the exhaustivity/unreachability warnings are supposed to be conservative. The analyses have been rewritten from scratch. Spurious warnings are a bug, please assign them directly to me. |
@paulp said: There is no reason f2 and f3 in the following can't give the same warning which f1 does. We have exactly the same information about what is covered and what is not in each of them. It would be very useful if this worked. sealed trait Foo
class Bar1 extends Foo
class Bar2 extends Foo
class Bar3 extends Foo
object Baz1 {
def unapply(x: Bar1): Some[Int] = Some(1)
}
object Baz2 {
def unapply(x: Bar2): Some[Int] = Some(2)
}
object Test {
def f1(x: Foo) = x match {
case _: Bar1 => 1
case _: Bar2 => 2
}
def f2(x: Foo) = x match {
case _: Bar1 => 1
case Baz2(x) => x
}
def f3(x: Foo) = x match {
case Baz1(x) => x
case Baz2(x) => x
}
} |
@paulp said: |
@paulp said: |
@adriaanm said: |
@adriaanm said: |
The following code fails to produce a non-exhaustive pattern warning when compiled with Scala 2.9.0-RC3 and above. The warning does get emitted with versions 2.9.0-RC2 and 2.8.1.
The text was updated successfully, but these errors were encountered: