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

[andcea]

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",
    };

This fails with a compilation error:

The type 'BaseType<A>' is not exhaustively matched by the switch cases since it doesn't match 'ChildB<dynamic, dynamic>()'.
Try adding a wildcard pattern or cases that match 'ChildB<dynamic, dynamic>()'. dart(non_exhaustive_switch_expression)

I'm not sure why it asks for ChildB<dynamic, dynamic>().
I don't want to use that as I'll loose type information.

I expect the matched type ChildB<A, dynamic> to be enough.

Tested using Dart version 3.2.6

[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.

[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]

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

[eernstg]

@rubenferreira97 wrote:

Using a variable pattern works:

That's because ChildA _ is a variable pattern whose type annotation ChildA is a raw type. This means that it denotes the result of instantiation to bound, that is, ChildA<dynamic>. So your example is the same as the following:

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<dynamic> _ => "ChildA",
  ChildB<dynamic, dynamic> _ => "ChildB",
};

.. which makes the switch exhaustive, but also reduces the precision of the typing in each branch of the switch.

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

That's the core of the issue, the case ChildB<A, dynamic>() isn't analyzed sufficiently effectively to allow the exhaustiveness analysis to conclude that we're definitely handling every possible scrutinee.

Basically, the problem is that there is a need to transfer information from the type of the scrutinee, BaseType<A> to the type of the case ChildB<A, dynamic>, such that it is guaranteed that the type arguments <A, dynamic> do not rule out any of the possible scrutinees. In other words, we must prove that if the scrutinee (of type BaseType<A>) is also of type ChildB<...> then it is guaranteed to also be of type ChildB<A, dynamic>.

Some thoughts about how this could be achieved can be seen in #4286.