Exhaustiveness checking fails on sealed classes with multiple generic parameters, even with `inout` variance

[omar-mohamed-khallaf]

I am encountering a non-exhaustive switch error when using a sealed hierarchy with two generic parameters. While I understand this is a known limitation, I wanted to highlight that enabling the experimental variance feature and marking the primary parameter as inout "invariant" does not resolve the issue. The compiler still fails to prove that the subclasses cover the full type space for a specific generic instance.

# analysis_options.yaml
analyzer:
  enable-experiment:
    - variance

abstract class Table {}

sealed class Criterion<inout T extends Table> {}

sealed class Constraint<inout T extends Table, V> extends Criterion<T> {}

final class BoolConstraint<inout T extends Table> extends Constraint<T, bool> {}
final class StringConstraint<inout T extends Table> extends Constraint<T, String> {}

void evaluate<T extends Table>(Criterion<T> criterion) {
  // ERROR: The type 'Criterion<T>' is not exhaustively matched by the switch.
  // It suggests that 'Constraint<Table, Object>' is not covered, 
  // even though T is invariant.
  final result = switch (criterion) {
    BoolConstraint<T>() => 'bool',
    StringConstraint<T>() => 'string',
  };
}

The compiler expects the switch to cover Constraint<Table, Object> (the top-level bounds) rather than recognizing that for a specific Criterion<T>, the only valid subclasses in this sealed hierarchy are those bound to that same T.

With inout variance, the compiler should be able to guarantee that Constraint<T, V> is the only branch to follow, and since all subclasses of Constraint are accounted for, the switch should be exhaustive.

[lrhn]

Known issue, and it's working as specified.
See #3866/dart-lang/sdk#53486

[omar-mohamed-khallaf]

I'm not sure I understand all that, but what I understand is that this case is non-trivial forwarding because generic parameters don't match (second type parameter V), and the compiler gives up and does something else (i.e., overapproximation).

My initial understanding was that this is because of covariance, but I think it's not the case here even though invariance can be used by the compiler to prove that the switch statement is exhaustive, right?

[mraleph]

I would guess that variance experiment is not really actively maintained or integrated with language features which arrived after it was implemented. Maybe we should disable the experiment flag altogether (given that it is not under active maintenance), though I don't know if we have procedure for doing that without deleting the code?

cc @leafpetersen @eernstg @kallentu

[eernstg]

I'd prefer to get it finished and shipped. I think it's a matter of priority rather than undesirability.