Spurious non-exhaustivity warning

Compiler version

3.2.0 with -Ycheck-all-patmat

Minimized code

sealed trait Nat
case class Zero() extends Nat
case class Succ[N <: Nat](n: N) extends Nat

type PredOrZeroOption[N <: Nat] <: Option[Nat] = N match
  case Zero => None.type
  case Succ[predN] => Some[predN]

trait A[N <: Nat]:
  def foo: PredOrZeroOption[N]

object A:
  def unapply[N <: Nat](a: A[N]): PredOrZeroOption[N] = a.foo

class B[PredN <: Nat](n: PredN) extends A[Succ[PredN]]:
  override def foo: Some[PredN] = Some(n)

@main def main(): Unit =
  val a = B(Zero())
  a.foo match
    case Some(pred) => println(pred)
  a match
    case A(pred) => println(pred)

Output

match may not be exhaustive.

It would fail on pattern case: _: B[Zero]

Expectation

No warning.

Note there is no warning for the a.foo match, which is equivalent.

[Bersier]

@dwijnand Thank you! Makes sense.

One thing that might improve upon the current state of affairs would be to have two different types of warnings:

1. when the compiler is sure that the match is not exhaustive
2. when the compiler is not sure whether the match is exhaustive

The latter warnings could be shown only when somehow enabled.

P.S.: The latter warning could also be split further into two sub-cases:

1. The compiler knows it will never be able to prove whether the match is exhaustive, because of non-sealed types or because it’s uncomputable.
2. The compiler doesn’t know whether it’s provable, and a future version of the compiler might know.

[dwijnand]

@dwijnand So are all flags mentioned here unreliable and not to be used? I use a lot of them:

Yeah, that’s what private means…

What are the alternatives?

Mostly there aren’t. Things like explicit nulls and safe-init will become on by default. But debug pos I don’t even understand why you use it, but I also don’t know what it does. But it sounds like an always private flag. In general they need a ticket, a reason and an effort to become stable, non-private feature or on by default.

For this flag specifically: how can I get a guarantee that all my matches are exhaustive otherwise?

There’s no (public) feature for that. But I would also want it, so I would back a proposal to add that. I’m fairly certain we had a flag like that in Scala 2.

Even if it’s not a bug for Scala 3 in general, isn’t it still a bug for this flag that should be tracked somewhere? It says in the document that it’s “used for testing the algorithm”. Doesn’t this spurious non-exhaustivity warning indicate some issue?

Sure, sort of. For some code we don’t check for exhaustivity, it doesn’t seem to calculate the right thing. It’s not worth keeping a ticket open for that - IMO.