Pattern matching non-exhaustive error on sealed class and multiple type parameters about language

[andcea]

@rubenferreira97 when using a variable pattern the variable type becomes ChildB<dynamic, dynamic>, which is why it works. The type should be kept as ChildB<A, dynamic>

[rubenferreira97]

Using a variable pattern works:

sealed class BaseType<A> {}

class ChildA<A> extends BaseType<A> {}

class ChildB<A, B> extends BaseType<A> {}

test<A>(BaseType<A> a) => switch (a) {
      ChildA _ => "ChildA",
      ChildB _ => "ChildB",
    };

void main() {
  for (int i = 0; i < 10; i++) {
    print('hello ${i + 1}');
  }
}

I try to always follow @lrhn's advice 'Always use the object pattern' #2963 (comment). However, this advice does not work here. It seems you have encountered a different analysis between an object pattern and a variable pattern. I don't know if it's a bug.

Maybe it's impossible due the differences between them, but I really wish that the object and variable patterns could be consistent with each other.

[rubenferreira97]

True, I tried the following explicit version and it still errors:

test<A>(BaseType<A> a) => switch (a) {
      ChildA<A>() => "ChildA",
      ChildB<A, dynamic>() => "ChildB",
    };

I can't find a valid reason for this not to work, but maybe the Dart team can answer 🙂.

[lrhn]

This is likely working as specified, and it is a known short-coming of the exhaustiveness algorithm.

The algorithm sees ChildB<A, Object?> and doesn't know how B of Child<A, B> affects exhausting the supertype BaseType<A>, since there is no B in the supertype.
So it gives up, and says you have to exhaust all of ChildB, meaning ChildB<Object?, Object?>, otherwise it can't be sure that you've exhausted all values of ChildB that can be a BaseType<A>. (That's called "overapproximation" in the specification. It's a guaranteed sound approximation to what you need to exhaust, but not minimal.)

A larger example showing the same thing:

sealed class BaseType<A> {}

class ChildA<A> extends BaseType<A> {}

class ChildB<A, B> extends BaseType<A> {}

test<A>(BaseType<A> a) => switch (a) {
      // Not exahustive. Infers type arguments and promotes.
      ChildA() => "ChildA: "
          "${a..st<E<ChildA<A>>>()}",
      ChildB() => "ChildB: "
          "${a..st<E<ChildB<A, Object?>>>()}",
    };

test2<A>(BaseType<A> a) => switch (a) {
      // Exhaustive. Instantiates to bounds, does not promote.
      ChildA v => "ChildA: "
          "${a..st<E<BaseType<A>>>()}, "
          "${v..st<E<ChildA<Object?>>>()}",
      ChildB v => "ChildB: "
          "${a..st<E<BaseType<A>>>()}, "
          "${v..st<E<ChildB<Object?, Object?>>>()}",
    };

test3<A>(BaseType<A> a) => switch (a) {
      // Not exahustive. Explicit type arguments, promotes.
      ChildA<A> v => "ChildA: "
          "${a..st<E<ChildA<A>>>()}, "
          "${v..st<E<ChildA<A>>>()}",
      ChildB<A, Object?> v => "ChildB: "
          "${a..st<E<ChildB<A, Object?>>>()}, "
          "${v..st<E<ChildB<A, Object?>>>()}",
    };

test4<A>(BaseType<A> a) => switch (a) {
      // Exhaustive. Explicit super-typed arguments.
      ChildA<A> v => "ChildA: "
          "${a..st<E<ChildA<A>>>()}, "
          "${v..st<E<ChildA<A>>>()}",
      ChildB<Object?, Object?> v => "ChildB: "
          "${a..st<E<BaseType<A>>>()}, "
          "${v..st<E<ChildB<Object?, Object?>>>()}",
    };

extension<T> on T {
  void st<X extends E<T>>() {}
}

typedef E<T> = T Function(T);

The two switches where the second case pattern doesn't cover all of ChildB<Object?, Object?> are not exhaustive. The two cases where they do, are.

See also dart-lang/sdk#53486