Can we temporarily remove "cannot extend mixins" limitation?

[yjbanov]

(branched off #31 (comment))

Goal

Migrate all mixins (not only super-mixins) to the new mixin syntax.

Background

Classes that were meant to be super-mixins already had restrictions matching those of the new mixin keyword. This makes the migration from class to mixin for super-mixins simple. That's not the case for non-super-mixins. Those classes are extended, implemented, and mixed in in the wild. Therefore changing what previously was declared as a class to a mixin breaks classes that used extends instead of with.

Proposal: temporarily allow extending mixins

• It does not require migration of any code that uses mixins, only code that defines mixins
• extends and with have no semantic differences observable by the developer
• It does not conflict with the new mixin semantics

Beyond that, this allows us to remove the ability to derive a mixin as a non-breaking change. To do that we will have to overload what extends means.

Imagine this declaration:

class Foo extends Bar

The compiler first checks whether Bar is a mixin or a class.

If Bar is a mixin, then the compiler desugars the above declaration into:

class Foo extends Object with Bar

More generally, class Foo extends M1 with M2, ..., Mk desugars into class Foo extends Object with M1, M2, ..., Mk.

If Bar is a class, then it's a normal derivation. The lint prefer_mixin then can be used to help authors find classes used as mixins and convert them to mixin syntax without breaking their users.

This approach will allow converting the vast majority of mixins present in the Dart ecosystem to the new mixin syntax without breaking existing user code. For example, Flutter can update abstract class WidgetsBindingObserver to mixin WidgetsBindingObserver as a non-breaking change.

Changing from class to mixin still comes with mixin restrictions, just like new mixin proposal wants, such as:

• mixins cannot extend other classes
• mixins cannot have constructors and factories
• mixins cannot be instantiated directly

These properties will protect mixin authors from accidentally breaking their users.

Discussions elsewhere

This topic was discussed on these other threads:

• use WidgetsBindingObserver as a mixin flutter/plugins#797
• Enforce that WidgetsBindingObserver is only used as a mixin or interface flutter/flutter#22290
• Is mixin for non-supermixins a good idea? #33

Updates

• Added a "Goal" section
• Removed argument that A extends M is simpler syntactically due to existence of A with M
• Created a section with links to other discussions

@leafpetersen @lrhn @eernstg @Hixie

[Hixie]

Personally I have no objection to being able to use "with" with a true class. I would not want a lint that discourages such use.
I don't see much value in the "mixin" keyword. I'm ok with having it if it makes the language easier to process in the context of supermixins. I would not encourage people to move to that keyword except where required by the supermixin restrictions.
In particular, I would not change WidgetsBindingObserver to use the "mixin" keyword.

[yjbanov]

Yeah, I should have mentioned that @Hixie and I do not agree on everything mixin-related (e.g. I disagree with #32 (comment)). However, we both agree that the restriction on extends is excessive.

Update: added "do not" in a critical place of the previous paragraph! 😄

[matanlurey]

I think the language is/was relaxing with, i.e. this would be legal:

class Foo with Bar {}

... negating the need to use extends Bar to avoid the boiler-plate of extends Object with Bar.

[yjbanov]

@matanlurey this is mentioned as a future possible feature, but that's not what's launching in Dart 2.1.

The second trouble with with is that it still requires that we update all the call-sites. Therefore, migrating from class to mixin is no longer limited to mixin declarations. The difference in scope is several orders of magnitude.

[matanlurey]

@yjbanov:

but that's not what's launching in Dart 2.1.

🤕

The second trouble with with is that it still requires that we update all the call-sites.

It seems reasonable that, for Dart >= 2.1.0 < 3.0.0, a mixin M should allow C extends M. In say, 2.2.0, when a C with M is allowed, a compile-time hint could be issued to suggest users refactor C extends M to C with M.

To be honest though, are there concrete reasons to prevent C extends M? I've seen classes that are intended to be used a mix-in, but I don't recall ones that are intended to be used as a mix-in but are prohibited to be used as a base class.

(I don't know if the new mixin M on T syntax makes C extends M impossible)

[yjbanov]

FYI, I filed #33 to discuss whether the mixin keyword is good for non-supermixins. Please post your thoughts there. I'd like this issue to stay focused on the extends keyword.

[yjbanov]

To be honest though, are there concrete reasons to prevent C extends M? I've seen classes that are intended to be used a mix-in, but I don't recall ones that are intended to be used as a mix-in but are prohibited to be used as a base class.

In this issue I suggest that extends changes its meaning depending on whether you are extending a class or a mixin, which removes the reasons for having the restriction. In the vast majority of cases the difference is not observable by developers, so there's no need to teach them about extra concepts.

[lrhn]

This is mentioned as a future possible feature, but that's not what's launching in Dart 2.1.

I do believe class C with M {} is planned for Dart 2.1, to be released at the same time as mixin declarations. Both the front-end parser and the analyzer already support the syntax.
(It's just equivalent to class C extends Object with M {}, so it's not a big feature to implement).

[lrhn]

Let's be specific.
@yjbanov You are suggesting that the following should be valid:

mixin M {}
class B {}
class C1 extends M {}
class C2 with M {}
class C3 extends B {}
class C4 with B {}

Here the line extends M changes meaning to really mean with M (aka. extends Object with M), and the rest keep their behavior.

Should we also allow:

mixin M2 {}
class C5 extends M with M2 {}
class C6 extends M, M2 {}

?
I'd argue vehemently against the latter, and merely strongly against the former.
The latter is very, very confusing, because you can only do that with mixins, not with classes, so the user still needs to know the difference. (I believe they always need to know, assuming you can use Dart correctly without knowing the difference will not end well).

The former would mean that we are not just reinterpreting extends M as with M, we are rather reinterpreting it as extends _Object$M where we declare class _Object$M = Object with M; implicitly (which isn't a bad definition of it).

So, yes, we can definitely allow extends Mixin as equivalent to extends _Object_with_Mixin.
We chose not to because it requires users to keep mixins and classes separate.

[yjbanov]

@lrhn I agree that, ignoring existing Dart code for a moment, class C extends M doesn't make sense given that class C with M exists (which I didn't know until now!). However, we can't ignore existing Dart code. It will make the migration much easier if we continued supporting class C extends M for some time by rewriting it to class C with M in the compiler. We do have Flutter non-supermixins that are extended by users. I also saw dart: mixins extended in the wild, such as extends ListMixin. Given how easy it was to find these real world occurrences, we must have a lot of these in the wild.

We could have an analyzer hint suggesting that users replace extends with with for, say, 6 months, before enforcing it.

Because this is mostly for migration (I agree that class C with M is as simple as class C extends M), I do not suggest that we support class C6 extends M, M2. Such code does not exist in the wild.

class C5 extends M with M2 has a decent chance of existing in the wild. However, I have not seen examples of that. I would say let's support it and rewrite it to class C5 with M, M2, because we don't want to be surprised later? I'm not super sure about it.

[leafpetersen]

I would not encourage people to move to that keyword except where required by the supermixin restrictions.
In particular, I would not change WidgetsBindingObserver to use the "mixin" keyword.

This comment and surrounding discussion had led me to think your desire was to migrate all mixins to the new syntax. If this is not the case, we should just change the lint to match up what you want. My main goal is to get the super mixins migrated over.

[leafpetersen]

The former would mean that we are not just reinterpreting extends M as with M, we are rather reinterpreting it as extends _Object$M

@lrhn can you elaborate on why? Maybe it's just late, but I'm not sure I'm seeing how you can observe the difference in the non-super-mixin case.