opt-out for old-school mixin-like classes from prefer_mixin

[goderbauer]

Flutter has some classes (like ChangeNotifier and WidgetsBindingObserver) where we tell developers that those can be extended, implemented, or mixed-in. However, the prefer_mixin lint is not happy when they are used as a mixin in a with clause. Since those classes pre-date the introduction of actual mixins in Dart, it would be nice if they can be opted out from the lint, e.g. by annotating them with something like @legacyMixin.

The Dart SDK also has some of these legacy mixins that would benefit from such an annotation (example: IterableMixin) to avoid the prefer_mixin warning in the following code snippet:

/// info: Prefer using mixins. (prefer_mixin)
abstract class Foo with IterableMixin<int> {
  // ...
}

/cc @pq @Hixie @mit-mit @munificent @devoncarew

[bwilkerson]

If the annotation were to be used in the SDK it would need to be defined in the SDK, so I'll cc a couple more people: @leafpetersen @lrhn.

[leafpetersen]

@lrhn should we consider making a plan to migrate SDK class mixins to mixin mixins?

[lrhn]

@leaf Absolutely.

It's breaking because someone might be extending the existing class, and you can't extends Mixin.

The best solution we've come up with for that is to allow extends Mixin to be equivalent to extends Object with Mixin. That would make it non-breaking to change existing classes-used-as-mixins to actual mixins, and bring us one step closer to simply disallowing classes as mixins entirely (which was always the goal).
See: dart-lang/language#1068 (comment)

We just hoped we could avoid the extends Mixin because it might cause more confusion about what a mixin really is, and how it differs from a class, but after a significant time, there has been zero progress on actually migrating people off class-mixins.

So, let's do it. Allow extends M to refer to a mixin declaration, in which case it's equivalent to extends Object with M (or just with M , which is the recommended syntax that is also equivalent to extends Object with M).
It's not purely syntactic replacing extends with with in case there is a following with, so extends M1 with M2 becomes with M1, M2, and we need to consider the class C = M with M2; syntax and also allow a mixin in the M position there, meaning class C = Object with M, M2.

With that in place, it should be a non-breaking change to switch a class declaration which is intended as a mixin, to be a mixin declaration. Then we can start bugging people about using classes as mixins (effectively deprecating that feature, so we can remove it eventually, like in Dart 3.0), and about using extends Mixin instead of with Mixin, but their code will keep running.

I'll file an issue: dart-lang/language#1529
(Pretty sure I've suggested this before, but couldn't find an issue).

[bwilkerson]

See also #47437

[parlough]

Thanks everyone for the discussion.

Now that the mixin class modifier now exists, the SDK migrated to use it ands so did Flutter (which was also able to enable prefer_mixin).

As a result, I don't think an opt-out would be worth it at this point. Any new code needing this functionality can use mixin class, so the only situation that remains is using with LegacyMixin in a Dart 3+ file where LegacyMixin is declared in a pre-Dart 3 file as a class. That non-Dart 3 file can relatively easily migrate to a language version of Dart 3 or later to switch to a mixin class.

Any concerns about closing this? :)

[lrhn]

No concerns.

The mixin class declaration was introduced specifically to cover use-cases like this, so we could migrate away from classes being incident mixin -able without it being breaking.