Does the pattern proposal make a breaking change on constant classes?

[leafpetersen]

This program:

class A {
  const A();
}

class B {
  const B();
}

void main() {
  Object o = A();
  switch (o) {
    case A(): print("A"); break;
    case B(): print("B"); break;
    default: print("other"); break;
  }
}

prints "other" in current Dart. Am I correct that the patterns proposal would re-interpret this syntax from two constant patterns A() and B() to two type test patterns, with the result that this would print "A"? If so, this should probably be called out as a breaking change (or is it already, and I missed it)?

There is some existing analysis on how breaking the re-interpretation of named constants would be, does that cover this change?

[munificent]

Ah, good catch! I didn't notice that extractor patterns also overlap with const constructor calls.

Yes, this is technically a breaking change, just like list and map patterns are. For collection literals, I found literally zero uses of collection literal syntax in switch cases in the wild. I haven't looked to see how many cases are const constructor calls. I'll do that and leave this open to track that. (I suspect there are almost none.)

[munificent]

OK, I analyzed a bunch of cases. The full comment is here. Out of 94,249 switch cases in 18,672,247 lines of code in 102,015 files, 11 were const constructor calls.

I think this issue is a subset of the larger issue #2408 which says that patterns doesn't support all valid const expressions that are currently allowed. I'm going to close this as a duplicate of that one since I think the solution, whatever we pick, should generalize across all constant expressions.