Add "mixin class" to the "base-interface-final" proposal.

[munificent]

I went ahead and took the more aggressive step of also saying that you can't mixin a class unless it has the "mixin" modifier. However, that rule is gated by a language version so that it's not breaking.

Since "mixin class" allows you to preserve the previous behavior of class+mixin, I think we can get away with doing this change in one step. Basically, whenever you upgrade your library to the latest version, you add "mixin" to whatever classes you want to support being used as mixins and you're done.

If you think that's too aggressive, let me know and I can change this. If we do that, though, it ends up meaning that the "mixin" modifier doesn't actually do anything (except yell at you if you apply it to a class with a generative constructor or non-Object superclass).

Lasse, I really like your suggestion for "mixin class". I think this lets us close the loose end of ChangeNotifier henceforth and forever without a lengthy migration and lets us support a rare but potentially useful combination of capabilities.

@mit-mit @eernstg @stereotype441 @jakemac53 @natebosch @kallentu

[natebosch]

Do we expect that authors of classes used as mixins are reliably aware of that usage?

I think this is worth the risk as long as it's not breaking to add mixin to an existing class so that we can safely republish if we find there is a critical use case.

[lrhn]

I expect authors of classes that are intended to be used as mixins to be aware of that (because they have documented it on the class, otherwise they probably didn't intend it).

It should not be breaking to add mixin to a class declaration. Adding mixin puts restrictions on the class itself (no generative constructors declared, no superclass other than Object), but if the class was used as a mixin before, it already satisfied those constraints. From the outside, adding mixin just allows you to mix in the class, it doesn't prevent anything.

Adding base and not mixin may break code that depended on mixing in the class, because they no longer can.
That means that forgetting to add the mixin is the breaking change. If the class is intended as a mixin, your own tests should catch that.

Changing a class that was not intended as a mixin into a class that cannot be used as a mixin might break users who used it as a mixin anyway.
Preventing such unintended use is the point of restricting you to mixing in classes that are declared as mixin class, so it'd be working as intended in breaking those classes.

[eernstg]

I hope we can do this! However, it could be helpful to get some input from the Flutter team: Which and how many classes do they expect to turn into mixin classes? Do they know, or would they be worried about finding them? Luckily, lots of classes just become an error if mixin is added, which means that they can be ruled out immediately (that is, they aren't in use as mixins).

[lrhn]

LGTM, ship it!

[eernstg]

Suggested a couple of typo-level changes

[munificent]

However, it could be helpful to get some input from the Flutter team: Which and how many classes do they expect to turn into mixin classes?

Excellent point. I'll reach out to them.