Linter: `prefer_mixin` should whitelist (some) library-defined abstract class mixins

[pq]

The lint fires, for example, here:

class AnalysisResults with IterableMixin<AnalysisResult> {

}

as IterableMixin looks like this in the SDK:

/// This [Iterable] mixin implements all [Iterable] members except `iterator`.
///
/// All other methods are implemented in terms of `iterator`.
abstract class IterableMixin<E> implements Iterable<E> {

}

IMO, we shouldn't flag this use.

[bwilkerson]

@lrhn Will mixins like IterableMixin be converted in the upgrade to Null Safety?

[lrhn]

There are no plans to make that change in the current SDK iterations.

I hope we'll eventually get around to deprecating classes-used-as-mixins, but it is a breaking change to change class to mixin in case someone does extends ClassName somewhere.
So we'll need a migration step (or allow extends MixinName as a shorthand for extends Object with MixinName (aka with MixinName).

[bwilkerson]

In that case, yes, we probably ought to special case the classes in the SDK that are intended to be used as mixins.

[pq]

Thanks for the follow-ups. A quick scan comes up with these initial candidates:

• IterableMixin
• ListMixin
• MapMixin
• SetMixin
• StringConversionSinkMixin (dart:convert)

Chime in if there are any I missed? 👍