Mixin declaration allowing super-invocations.

[lrhn]

Solution for issue #6.

See the feature specification document.

Implementation issue: #12

Introduce a new syntax for declaring mixins:

mixin Mixin<TypeArgs> on SuperType1, SuperType2 implements I1, I2 {
  member-declarations
}

This declaration introduces a mixin, like one derived from a class, except that the mixin can only be applied to a super-class which implements SuperType1 and SuperType2. In return, it can then do super-invocations targeting members of the SuperType1 or SuperType2 interfaces.

Each time this mixin is applied to a super-class, it must check that all the members that are invoked by super-invocations actually have implementations in the super-class which satisfies the most specific requirement of SuperType1 and SuperType2 for that member.

[Hixie]

This seems like a reasonable proposal.

A possible slightly change would be to use the word "class" instead of the word "mixin" to declare mixins, and have that automatically define both a mixin and a class, and then to enforce the rules for mixins only when the identifier is used as a mixin. It seems like that would get all the benefits of the proposal while simultaneously avoiding having a backwards-incompatible change in syntax. Is there a reason I'm missing why that would not be possible?

[munificent]

I'm worried the on keyword is a little too opaque. Given that implements and extends are already pretty long, what do you think of requires? In the strawman, you consistently use "requirement" to refer to those, so it seems like that is the natural word for what's being described.

A possible slightly change would be to use the word "class" instead of the word "mixin" to declare mixins, and have that automatically define both a mixin and a class, and then to enforce the rules for mixins only when the identifier is used as a mixin.

In practice, most classes that we see today used as mixins are intended to only be used as mixins. Many even put "Mixin" in the class name. So it doesn't seem like having dual-use types is a highly valuable affordance.

By prohibiting using the mixin as a class, it means the author of the mixin doesn't have to worry about accidentally breaking users when they change the mixin in a way that makes it no longer a usable class (like adding an abstract method, etc.). It's roughly analogous to sealed classes, final methods etc. It lets the author narrow the scope of what future changes may break users.

Also, I think it gives users a clearer expectation of how to use the type. It lets the API author give users a more "on rails" experience.

It might be worth adding a way to explicitly opt in to defining a "mixin and class" type, but my feeling is that it's not a good default behavior.

[leafpetersen]

A possible slightly change would be to use the word "class" instead of the word "mixin"
A possible slightly change would be to use the word "class" instead of the word "mixin"

It's definitely possible, with various caveats. It has some downsides though.

One (mentioned in the proposal) is simply that allowing classes to be used as mixins makes it harder for library writers to control what is a breaking change. So having a separate construct for the separate intended use provides some benefits independent of anything else.

Another downside (or advantage of the new syntax, if you prefer) is that the class syntax doesn't tell the client which interfaces should be satisfied by the superclass, and which can be satisfied in other ways (e.g by the mixin itself, or by the class that the mixin is being mixed into).

Compare:

class A extends B implements C, D {...}

versus

mixin M on B, C implements D { ...}

the latter makes it clear that M should be mixed onto something satisfying B and C. For A, it's not clear what subset of B, C, and D are required by the superclasses. This is especially confusing if a super called method is provided by (say) both C and D. Does that mean that both C and D must be in the superclass chain? Or exactly one? Or at least one?

There are also compilation benefits to knowing whether something is intended to be used as a mixin or a class, particularly in a modular setting. If a compiler needs to be prepared for the possibility that any suitable class might be used as a mixin, then it is more restricted in the set of optimizations that it can do (such as inlining super calls).

[leafpetersen]

I'm worried the on keyword is a little too opaque. Given that implements and extends are already pretty long, what do you think of requires?

This was considered. I don't have strong feelings either way. The on keyword makes a lot of sense to me, since I think of applying a mixin as mixing it "on" to the super class, but thinking of it in terms of what the mixin "requires" of the superclass also makes sense.

@lrhn might have more thoughts. It's something I'd definitely be interested in hearing from other folks about.

[Hixie]

Just to clarify, I definitely like the "mixin" keyword, and I think it's a good idea, for all the reasons given above. I'm greatly concerned about yet another breaking change, however. One option would be to support both but have a lint that discourages the old style.

[Hixie]

(To handle the compiler issue, one option would be to have a compiler mode that just disables the legacy syntax for codebases that know they don't use it.)

[munificent]

The on keyword makes a lot of sense to me, since I think of applying a mixin as mixing it "on" to the super class

My impression from talking about and explaining mixins to lots of users is that almost none of them actually internalize the Bracha-ian notion that a mixin is a function that is applied to a superclass, so "on" probably doesn't illuminate much. Also "on" to me reads like a thing it does not a thing it needs.

I'm greatly concerned about yet another breaking change, however. One option would be to support both but have a lint that discourages the old style.

The doc does state:

It expects to deprecate and remove the ability to derive a mixin from a class declaration, but doesn't require it.

My expectation is that we would add the new syntax, only allow super calls in mixins that use the new syntax but also support the old syntax and semantics for regular non-super-calling mixins. The set of mixins that use super calls is vanishingly small. I wouldn't be entirely surprised if you were literally the author of a majority of them. :)

[Hixie]

For the on issue: Maybe we could create a survey that presents people with a snippet of code, and ask them what they think it means (without reference to this proposal). If we put out several such surveys, we could find out which syntax idea is clearest. Maybe @InMatrix has some more rigorous ideas for how to do this. It seems like something eminently testable empirically.

For the backwards-compatibility issue: Could we instrument the analyzer to catch such cases, and anonymously report them? Flutter in particular has an analytics mechanism we could reuse for this. Obviously if all the uses are in the Flutter framework then there's no breakage concern.

[leafpetersen]

Just to be sure that we're on the same page, we're not intending to remove support for using classes as non super-mixins , at least yet. We'd like to do so in the future, but that would depend on driving usage low enough, and even then... well, we'll see.

For super-mixins, there is no existing web code that uses them (they're not implemented), and the feature is not available even on the VM without turning on the experimental flag. So it's not breaking for direct consumers of the Dart SDK.

Unfortunately for us, of course, the flutter tools ship with the experimental flag turned on. So this will be a breaking change for flutter. This is actually true whether we introduce new syntax or not: see below for an example of two bad uses of super-mixins that I really, really, really want to disallow, whether we use new syntax or old. But it's certainly true that keeping the old syntax would make this less breaking.

This change is primarily breaking for library writers though. If you wrote the super-mixin correctly, then most of the time uses won't need to change. It's only the definition of super-mixins that will need to change. So most flutter users shouldn't even know this has happened. If their code worked before, it should continue working. The cases that they will be broken are:

• if they wrote their own super-mixins (need to migrate)
• they're using the mixin in an invalid way, but that currently works (need to migrate, would probably need to migrate even if we keep the old syntax).

My hope is that if we get out ahead of this with communication, this can be a minimally disruptive change to flutter users (and to the flutter framework). WDYT?

// This program passes the static analysis, and runs in the dart VM (throwing an error on the missing super call)
class A {
  void bar() {}
  void foo() {}
}

class B {
  void bar() {}
  void foo() {}
}


abstract class M extends A implements B {
  void baz() {
    super.bar();
    super.foo();
  }
}

// Doesn't provide an `A` to `M`.
class C extends B with M {
}

abstract class AbsA implements A {
  void bar();
  void foo();
}

// Doesn't give `M` the required super methods
abstract class D extends AbsA with M {
}


class E extends D {
  void bar() {}
  void foo() {}
}

void main() {
  C().baz();
  E().baz(); // Runtime error
}

[leafpetersen]

Maybe we could create a survey that presents people with a snippet of code

I'd be very happy to see data on this, with the caveat that for lots of reasons we need to move fast on this (not least of which is that the longer we wait, the bigger the chance that we break people). For small syntax changes like this, I think it would be reasonable for us to implement the feature simultaneously with doing surveys, and then just change the keyword if based on data before shipping to users. We'd need to get going on data gathering ASAP though.

Could we instrument the analyzer to catch such cases, and anonymously report them? Flutter in particular has an analytics mechanism we could reuse for this.

I would love to start getting analytics data about language and core library feature usage. Even if it's not feasible in time for this feature, it would be awesome if we could start getting this set up for future use. Not sure what would be involved - I don't think it would be technically hard in the analyzer, but there are lots of tricky issues. cc @devoncarew @bwilkerson

[leafpetersen]

I split off a new issue for discussion of the syntax choice for superclass constraints: #9 .