Exhaustive check on generic sealed class is considered not exhaustive

[rrousselGit]

Consider the following sealed hierarchy:

sealed class Base<A> {}

sealed class Mid<A, B> extends Base<A> {}

final class Final<A, B> extends Mid<A, B> {}

We can then use it with pattern matching like so:

void main() {
  Base<int> base = Final<int, Object?>();

  switch (base) {
    case Final<int, Object?>():
      print('42');
  }
}

The problem is, this switch is considered non-exhaustive.

To have the compiler consider the switch as exhaustive, we incorrectly have to change Final<int, Object?>() into Final<Object?, Object?>().

This is incorrect, because given Base<int>, it is guaranteed that all instances will implement Final<int, ...>

Removing the intermediary Mid class fixes the issue, so it probably has to do with the added level of indirection.

[simphotonics]

Using Dart SDK version: 3.5.4 (stable) on linux_x64 and DartPad,
the switch expression below is considered to be exhaustively matched:

sealed class Base<A> {}
sealed class Mid<A, B> extends Base<A> {}
final class Final<A, B> extends Mid<A, B> {}

void main() {
  Base<int> base = Final<int, Object?>();

  switch (base) {
    case Final<int, Object?>():
      print('42');
    case Base<int>(): // Analyzer does not complain.
      print('never reached');
  }
}

Should it be even possible to match an "instance" of an abstract class?

[lrhn]

This is a known shortcoming of the exhaustivness analysis. It doesn't work well with supertypes with type parameters that aren't used. See fx dart-lang/sdk#53486

That means that Final<int, Object?>() is not enough since the space it thinks it needs to exhaust is Mid<Object?, Object?>, and it only exhausts Mid<int, Object?>. That's because it can't figure out the connection between the B of Mid and Base<A>, so it gives up on both type parameters of Mid, and thinks you need to exhaust Mid<Object?, Object?> in order to exhaust Base<int>.
There is room for improvement in that area.

So case Base<int>() is considered reachable, and it does exhaust all of Base<int>. (The algorithm can see that.)

[eernstg]

Just to recapitulate, there are multiple issues dealing with a similar topic: #2963, #3633, #4199, and #4286 (and in general, exhaustiveness). Some ideas about how to address the underlying issue are discussed in #4286.