Skip to content

Exhaustiveness checker needs special rules for singleton types #4227

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

Closed
LPTK opened this issue Apr 2, 2018 · 1 comment
Closed

Exhaustiveness checker needs special rules for singleton types #4227

LPTK opened this issue Apr 2, 2018 · 1 comment

Comments

@LPTK
Copy link
Contributor

LPTK commented Apr 2, 2018

The following code (here on Scastie) generates an exhaustivity warning that seems unjustified:

sealed abstract class Maybe[A]
final case class Just[A](a: A) extends Maybe[A]
class Empty[A] extends Maybe[A]
object Empty {
  def apply[A](): Maybe[A] = new Empty[A]
  def unapply[A](e: Empty[A]): Some[Unit] = Some(())
}

object Test {
  val a: Maybe[Int] = Just(2)
  def main(args: Array[String]): Unit = a match {
    case Just(_) => 
    // case Empty(_) => // ok
    case Empty(()) => // match may not be exhaustive. It would fail on: Empty(_)
  }
}

Also (regardless of the fact that the warning is spurious), the error message says it would "fail on Empty(_)," but this is not even a valid expression (as in, I can't write val x = Empty(y)). If warnings are supposed to refer to patterns as opposed to expressions, maybe the message should read something like "pattern case Empty(_) not handled" instead.

@smarter
Copy link
Member

smarter commented Apr 2, 2018

Unit is not technically a singleton type, but it should behave like one for the purpose of exhaustiveness checking. However, we don't seem to handle singleton types for exhaustiveness checks currently:

 object Test {
  def foo(x: Option[1]) = x match {
    case Some(1) =>
    case None =>
  }
}
 2 |  def foo(x: Option[1]) = x match {
  |                          ^
  |                          match may not be exhaustive.
  |                          
  |                          It would fail on: Some(_)

@smarter smarter changed the title Spurious exhaustive pattern matching warning? Exhaustiveness checker needs special rules for singleton types Apr 2, 2018
@liufengyun liufengyun self-assigned this Apr 2, 2018
liufengyun added a commit to dotty-staging/dotty that referenced this issue Apr 3, 2018
liufengyun added a commit to dotty-staging/dotty that referenced this issue Apr 3, 2018
liufengyun added a commit that referenced this issue Apr 3, 2018
Fix #4227: handle singleton types in exhaustivity check
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants