Exhaustivity fails on Result<T, E> with Ok<T> and Err<E> where the other generic is Never

[TekExplorer]

Using the following sealed class

sealed class Result<T, E extends Object> {}

final class Ok<T> implements Result<T, Never> {
  const Ok(this.value);
  final T value;
}

final class Err<E extends Object> implements Result<Never, E> {
  Err(this.error, this.stackTrace);

  final E error;
  final StackTrace stackTrace;
}

See the following:

// this is ok, but we lose type information in the generics
check(Result<String, Exception> r) {
  return switch (r) {
    Ok<dynamic>() => throw UnimplementedError(),
    Err<Object>() => throw UnimplementedError(),
  };
}
// this SHOULD be ok, but the analyzer complains that we don't handle Ok<dynamic> and Err<Object>
check(Result<String, Exception> r) {
  return switch (r) {
    Ok<String>() => throw UnimplementedError(),
    Err<Exception>() => throw UnimplementedError(),
  };
}

I think there was an issue about this prior, but I can't seem to find it, so I'll make it here.

I noticed this issue as I was messing around with Result<T> and wanted to try specifying the specific error type

[johnniwinther]

This is a known limitation of the current support for exhaustiveness. We only recognize "trivial" subtype relations, such as class A<T> extends B<T>, where the type arguments to B are exactly the type parameters of A, or class A extends B<int> where the type argument to B is fixed.

@eernstg Do we have a language issue for this?

[eernstg]

I don't think so, and I can't find any, so I created dart-lang/language#4286.

[lrhn]

We do have some language issues related to this:

• Pattern matching non-exhaustive error on sealed class and multiple type parameters language#3633
• Unexpecte behavior in Exhaustiveness Checking With sealed classes and generics language#3866
• Exhaustive check on generic sealed class is considered not exhaustive language#4199

(Which I found linked from the SDK issue #53486)

[TekExplorer]

So this has been around for a while.

How come it hasn't been fixed then?

I ask because a language feature is effectively broken, which seems like a serious bug.

I have genuinely no understanding why the algorithm cant handle this case.

Seems simple enough to me:

• Result is sealed - has 2 subtypes: Ok, Err
• see Ok<T>
  • check types. T is a supertype of T
  • no other considerations can be made. Ok<T> is self-exhaustive
• see Err<E>
  • same logic
• exhaustive
  You just... don't care that one of the generics is hard coded internally because it doesn't matter.