Exhaustiveness error when using private mixins

[craigdfoster]

I have a flutter project that uses mobX for state management.

MobX augments classes using code generated private mixins taking the following form:

class MyClass = _MyClassBase with _$MyClass; 

abstract class _MyClassBase with Store {...}

// code-gen...
mixin _$MyClass on _MyClassBase, Store {...}

I've augmented this to create a sealed class hierarchy in an attempt to take advantage of switch exhaustiveness:

sealed class Base {...};

class MyClass1 = _MyClass1Base with _$MyClass1;
sealed class _MyClass1Base extends Base with Store {...}

class MyClass2 = _MyClass2Base with _$MyClass2;
sealed class _MyClass2Base extends Base with Store {...}

If I do a switch statement on these classes, the VSCode analyser doesn't report any issues, but in most scenarios they will cause a compiler error.

Error: The type 'Base' is not exhaustively matched by the switch cases since it doesn't match '__$MyClass1&_MyClass1Base&Store()'.

__$MyClass1&_MyClass1Base&Store is the definition for MyClass1, it's private and non-instantiable, so it should be ignored for exhaustiveness right?

There is one scenario where this works, extending the code above...

sealed class Parent = _ParentBase with _$Parent;
sealed class _ParentBase extends Base with Store {...}

class Child1 = _Child1Base with _$Child1;
sealed class _Child1Base extends Parent with Store {...}

class Child2 = _Child2Base with _$Child2;
sealed class _Child2Base extends Parent with Store {...}

Base x = Child1();
Parent y = Child1();

// DOES NOT COMPILE
switch (x) {
  case MyClass1():
  case MyClass2():
  case Child1():
  case Child2():
}

// COMPILES
switch (y) {
  case Child1():
  case Child2():
}

Note the minor difference between Base and Parent.

I have a demo project showing the issue here.

[lrhn]

it's private and non-instantiable, so it should be ignored for exhaustiveness right?

That's not a rule, no.

The problem here is the _$MyClass1 and _$MyClass2 mixins.
You say they are declared as:

mixin _$MyClass1 on _MyClass1Base, Store {...}

That defines a non-sealed subclass of the sealed _MyClassBase1, and the MyClass1 class is a further subclass of that.
Because of that, MyClass1 doesn't exhaust _MyClass1Base.

If the mixin had been sealed, it would have, but mixins can't be sealed.
If the rules that the on type of a mixin doesn't count towards exhaustiveness had been implemented, it would have worked.
But it wasn't, which left an unsoundness that was plugged by making it count.

So, the pattern doesn't really work with sealed

[craigdfoster]

Any plans to change this? It feels like a missed opportunity.

I understand the risk of not counting on types towards exhaustiveness, with the example outlined in #3275. But by counting on types the usability of sealed classes is severely curtailed. As you've said: my pattern just doesn't work with sealed, which effectively forces me into a choice between sealed classes and MobX. There's just no way of using mixins with sealed class hierarchies.

The core idea of sealed classes is that the compiler can statically derive a known, enumerable set of subtypes right? I feel my example should work because the private mixins cannot be implemented outside of the library (so there can be no unknown external subtypes) and the compiler created subtype __$MyClass1&_MyClass1Base&Store cannot be used in code so it could never be a subtype of concern with respect to switch statements or indeed the developer's design intent of the class hierarchy.

FYI - I tried declaring the mixins as base to further guard against out-of-library implementation and made MyClass1 etc final and same result.

[lrhn]

This is similar to dart-lang/language#3103, so I'm closing this and referring to the other issue (which I'll link back here for context).