use of custom unapply breaks exhaustivity checking

[fommil]

In 2.12.4 the following code (correctly) warns on compile due to exhaustivity checking

sealed abstract class Maybe[A]
final case class Empty[A]() extends Maybe[A]
final case class Just[A](a: A) extends Maybe[A]

Just(1) {
  case Just(2) => true
  case Empty() => true
}

but the following, with an alternative encoding of Empty (#10659) compiles without warning

  final case object Empty extends Maybe[Nothing] {
    def apply[A](): Maybe[A] = this.asInstanceOf[Maybe[A]]
    def unapply[A](e: Maybe[A]): Boolean = this == e
  }

Guessing, it looks like the presence of the "custom" unapply causes the more aggressive checkers not to trigger. Perhaps the presence of the custom unapply should only disable the aggressive checking around the Empty, not around the entire ADT Maybe.

// @xuwei-k

[sjrd]

Well of course it breaks exhaustivity checking, because the match might indeed not be exhaustive, if you replace the body of your unapply by false. The compiler has no way to inspect the body of your unapply to make a decision about exhaustivity.

[fommil]

Then it is broken in two ways. The one I care about is that it no longer warns that Just is not covered.

[sjrd]

Replace the body of your unapply by true and now Just is covered.

[fommil]

But that is then broken.

The custom extractor is against Maybe, so perhaps there is no way to fix this.

[sjrd]

But that is then broken.

You know that. The compiler has no idea.

[fommil]

yes, but that's just further evidence that the compiler should be more cautious, not less. It's almost like the exhaustiveness checker is assuming that Boolean unapply is returning true.

[TomasMikula]

So you would like a warning every time the compiler cannot prove exhaustiveness (as opposed to when it can prove non-exhaustiveness)?

[fommil]

That would be pretty good, yes! Effectively forcing pattern matches only for destructuring. I'm aware the motivating example is therefore excluded.

[SethTisue]

I'd love to have an annotation that fails compilation on non-exhaustive matches (somewhat like @tailrec). I looked for an existing ticket on that but failed, anyone know of one?

[fommil]

I did the same search when I wanted to close this as a dupe, and realised this is the closest we have. But my ticket search foo is pretty bad.

[fommil]

I added a custom unapply to the scalaz IList, looking like this

  object :: {
    def unapply[A](xs: ICons[A]): Option[(A, IList[A])] = xs match {
      case ICons(head, tail) => Some(head -> tail)
    }
  }

even though the input type is ICons, it still disables the exhaustivity checker for INil when used e.g.

ilist match {
  case head :: tail => ...
  // missing INil() but no warning!
}

in addition, the definition of an unapplySeq also breaks exhaustivity checking, e.g.

  def unapplySeq[A](ilist: IList[A]): Option[Seq[A]] = Some(ilist.toList)

It is debatable what should and shouldn't disable the matcher. But I feel it shouldn't happen silently (there is a scalafix request for this).