Is `mixin` for non-supermixins a good idea?

[yjbanov]

I'm filing this issue as a place to discuss whether using the new mixin syntax for non-supermixins is a good idea. I do not wish to pollute issue #32 with this discussion, as I'd like that issue to be focused on the semantics of extends w.r.t. mixin.

The arguments presented so far:

@Hixie (#32 (comment)):

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:

mixin comes certain restrictions on what you can do with the class, such as:

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

These properties protect mixin authors from accidentally breaking their users. I believe this is an important property for keeping the Flutter/Dart ecosystem healthy. Mixin usage is much higher than mixin authorship and therefore the cost of using mixin vs class is dwarfed by the stability guaratees the mixin semantics provide.

Some examples in Flutter that may be used as super-classes or as mixins:

• LocalHistoryRoute
• WidgetsBindingObserver

Updates to the original issue description:

• Added examples from Flutter

[yjbanov]

More arguments can be found in flutter/flutter#22290. For example:

My worry is that in the future we may accidentally break the API by adding a seemingly innocent super call or attempt to extend another class.

The solution to that is to add tests. I would certainly support adding more tests to make sure we don't break that particular pattern.

The solution to that is to add tests.

This solution works for highly disciplined engineering teams. But I don't think it works for the ecosystem as a whole, where you will have users of varying levels of expertise. Using classes as mixins is known to be quirky. If there is a better way, I say we should accept it. I think dart-lang/language#31 (comment) is a better way.

[lrhn]

The problem with allowing any (no-constructor, Object-superclass) class to be used as a mixin is that it makes more changes into breaking changes for that class.

Adding tests cannot catch this.

If someone else, in a package you never heard of, is using your class as a mixin (maybe even on a const class), then you break their code if you

• Add a generative constructor (e.g., by changing a factory constructor to be generative).
• Add a super-class.
• Add a first field (if used on const class, and someone uses the result as const)

These are not changes that would normally count as breaking, so most likely you won't do a major-version increment when you refactored the class to share some functionality with another class through a private super-class - but if they update their dependencies, their code stops working.

So, any API containing any class that can be used as a mixin, should do a major-version increment whenever they change such a class so it can no longer be used as a mixin.
Obviously nobody wants to do that, which is why there is this request to ensure that a non-mixin class cannot be used as a mixin.

[eernstg]

Why don't we simply answer "Yes, it is indeed a good idea to use mixin for a declaration M that is intended to be used as a mixin, even in the case where no method implementation in its body performs any superinvocations!"

The point is that this is a contract that involves the author(s) of M and the clients of M, and the software artifacts containing M are simply going to be more maintainable when such a tightly coupled piece of reusable code as a mixin is marked explicitly as such.

Do we need a 'resolution-yes' label? ;-)

[Hixie]

I don't see why mixins are special here. Any class can be used as an interface too, with the same problems.

[munificent]

Any class can be used as an interface too, with the same problems.

That's one of the reasons we're looking into sealed classes and the ability to express a class that cannot be implemented. The language already supports this for a hand-picked set of magic classes — bool, double, num, int, and String. If it's useful for those types, it's likely useful for user types.

[Hixie]

Sure, but most classes can't be sealed since they're intended to be subclassed, and almost all classes need to be implementable for mocking purposes.

[munificent]

Sure, but most classes can't be sealed since they're intended to be subclassed, and almost all classes need to be implementable for mocking purposes.

As far as I know, we don't actually have any real empirical data to justify a claim like that.

[yjbanov]

Adding tests cannot catch this.

More than that. In practice, few developers write tests.

I don't see why mixins are special here. Any class can be used as an interface too, with the same problems.

One special thing about mixins is that we are trying to fix them now. We are currently not trying to fix interfaces, which, I agree, also have problems. I guess I don't understand what conclusion this argument is trying to reach.

I'm also not sure if the problem are the same. For example, if a class is also used as an interface, then adding a factory or a generative constructor, extending another class, and adding super calls are rarely breaking changes. OTOH, these changes are guaranteed breaking changes in the case when a class is also used as a mixin.

Classes-used-as-interfaces do have issues though, and I think they should be addressed at some point. Some background is documented here.

most classes can't be sealed since they're intended to be subclassed, and almost all classes need to be implementable for mocking purposes.

Perhaps, but also most classes do not need to be fast. In practice, only a small portion of code is on the hot performance path, and that's where you will see benefits from things like sealed, static dispatch, memory-locality, etc. For example, Dart draws a lot of performance benefits from keeping int, double, String and bool sealed. What's changed recently is our realization that this could have impact beyond built-in classes. C++ is not fast because every single line of code your write is fast, but because it gives you the tools to make the 5% of code that does need to be fast fast.

Not that this particular issue has to do with performance. I'm just doubting the logic in the claim that a feature should be rejected because of low usage count. I think a feature's inclusion should be evaluated according to its overall impact.

[mit-mit]

@yjbanov @lrhn did we reach a conclusion here? Can we close this issue?

[yjbanov]

AFAICT, no conclusion has been reached yet.

[lrhn]

My opinion is definitely that, yes, it is a good idea to use mixin for all mixins.

I'm not sure what it would take to close this issue, though.

[munificent]

My opinion is definitely that, yes, it is a good idea to use mixin for all mixins.

Me too. But, either way, I think this is a question about best practices and not something actionable in the language repo. Maybe it would be worth filing a bug for what "Effective Dart" should say here, but that's a separate repo.

[yjbanov]

The goal of the issue is to get a recommendation from the language team so we could follow it in Flutter and steer our users towards it via analysis_options_user.yaml.

If the recommendation is to use mixin for all mixins, then we're back to issue dart-lang/sdk#57178, which prevents us from being able to follow the recommendation.