Flow analysis. Patterns match in switches

[sgrekhov]

The code below doesn't produce expected error in either CFE and the analyzer.

void test1() {
  late int i;
  switch (42) {
    case String _: // Warning: The matched value type 'int' can never match the required type 'String'. Try using a different pattern. • pattern_never_matches_value_type
      i = 42;
    default:
  }
  i; // Definitely unassigned
//^
// [analyzer] unspecified
// [cfe] unspecified
}

Flow analysis for patterns is not specified yet, but intuitively I'd expect an error here.

cc @stereotype441

Dart SDK version: 3.9.0-95.0.dev (dev) (Sun May 4 21:03:05 2025 -0700) on "windows_x64"

[lrhn]

Probably working as intended.

If you wrote the same example as:

void test1(Foo value) {
  late int i;
  switch (value) {
    case Bar _: i = 42;
    default:
  }
  i;
}

you wouldn't expect i to be definitely unassigned, because it's possible for a value to implement both Foo and Bar.

It's also possible for a value to implement both String and int. They're final classes, but final classes in the same library, so someone inside that library could choose to create an object which implement both.
They (we) currently don't (and never will), but that's not something that is codified in the language, and flow control and promotion can't know that it'll never happen.
(After all, the same logic could have mandated that no value implements both int and double, and yet all integers on the web dot hat.)

The warning about "can never match" comes from the analyzer, which makes more assumptions than the language itself.
It knows that String and int are special platform classes and will never intersect (or will currently not intersect, the analyzer can also change with the language and platforms).

For flow analysis to recognize that the branch is unreachable, that'll require special-casing for int and String, it's not a property of the code as such.
Promotion is in the language, and the language doesn't know that there is no IntString type, and I'd prefer to not add that.
(If we had a way to specify that a type is completely closed, so that no subclass can ever implement any new interface that isn't itself already a subtype, then we can know that such a type has no intersection with an interface that it doesn't implement itself.)

[stereotype441]

Closing since this is working as intended. @sgrekhov, feel free to reopen if you still have concerns.