Analyzer exhaustiveness-checking inconsistent for switch on record

[nex3]

This code:

bool doIt(Object arg1, [Object? arg2]) {
  switch ((arg1, arg2)) {
    case (_, null):
      return true;

    case (_, _?):
    // case (_, _):
      return true;
  }
}

produces this error with dart analyze on Dart 3.0.5:

  error - test.dart:2:6 - The body might complete normally, causing 'null' to be returned, but the return type, 'bool', is a potentially non-nullable type. Try adding either a return or a throw statement
          at the end. - body_might_complete_normally

However, if I uncomment the case (_, _): I get this info instead:

   info - test.dart:8:5 - This case is covered by the previous cases. Try removing the case clause, or restructuring the preceding patterns. - unreachable_switch_case

My expectation is that the first form should work, because it does exhaustively cover all possible cases of the input record. Regardless, it seems like the analyzer should at least be consistent about whether it considers this switch to be exhaustive or not.

[bwilkerson]

@johnniwinther I don't know who should look at this, but I'm hoping you know.

[johnniwinther]

I'll take a look at it.

[johnniwinther]

The problem is that the flow analysis uses the static type of the switch statement scrutinee to determine whether the switch is exhaustive. Because (Object, Object?) is not an always exhaustive type, it expects the switch to complete normally.

If the switch was written as a switch expression (which is always exhaustive) there is no problem in writing:

bool doIt(Object arg1, [Object? arg2]) => switch ((arg1, arg2)) {
      (_, null) => true,
      (_, _?) => true,
    };

@pq @bwilkerson In this case we probably shouldn't report a lint about the unreachable case, but instead suggest adding a default: case (or rewritting as a switch expression).

[nex3]

I'm surprised to learn that a switch statement's exhaustiveness status is determined only by the type of its argument, and not also by whether a return is required at its position.

[johnniwinther]

With "a return is required at its position" do you mean that it is the last statement of a non-void method?

cc @munificent

[nex3]

Well, that or it's in a conditional block that is itself the last statement of a non-void method, and so on.

[munificent]

Yeah, this is a known annoying pain point. It's a consequence of the fact that we do flow analysis separate from exhaustiveness checking. In a perfect world, we'd do those as one holistic process and you wouldn't run into this situation. I'm going to close this as a dupe of dart-lang/language#2977 and we can resume the discussion there.

The suggestion to treat a switch statement as always-exhaustive if it occurs in a position where a value must be returned is really interesting and one I honestly never considered. Thanks for bringing that up!