Function mixins

[munificent]

Here's a strawman proposal based on an idea by @leafpetersen.

Dart allows you to add behavior to classes in a compositional-ish way using mixins and with clauses. In #4359, I suggest extending that so that you can add behavior which is applied after the class body.

Here, I suggest a different generalization: we let you do something similar for function declarations. This is sort of like decorators in Python. When combined with augmentations, it gives you much of the ability of augmented() but (hopefully) in a more elegant way.

After all, Dart tries to place object-oriented programming and functional programming on equal footing, so why should classes have all the fun when it comes to compositionality?

Function mixin

A function mixin looks like a top-level function declaration preceded by the mixin keyword:

mixin void profile() {
  var stopwatch = Stopwatch()..start();
  super();
  print(stopwatch.elapsed);
}

Applying function mixins

A function mixin can't be called directly. Instead, it must be mixed into some other function declaration using a with clause. The clause can appear after the function body:

void someSlowFunction() {
  // Do something worth profiling here...
} with profile;

Multiple function mixins can be applied with a single clause:

void someFunction() {
  // ...
} with someMixin, another, aThirdOne;

A function declaration can also apply mixins before its own body:

void someFunction() with someMixin, another, aThirdOne {
  // ...
}

You can also apply function mixins to functions with => bodies:

void someFunction() with before => body with after;

(I admit that's not what I'd call beautiful. We can debate whether the body should have ; before the trailing with or not.)

Calling a function with mixins

Function mixins and the function's own body are linearized in the order that they appear. The function's own body is treated like an in-place function mixin declaration.

When the function is called, execution starts at the last mixin in the chain. If that mixin contains a super(...) call, then that calls the next mixin in the chain, and so on. For example:

mixin void before1() {
  print('before 1');
}

mixin void before2() {
  super();
  print('before 2');
}

mixin void f() with before1, before2 {
  super();
  print('f()');
} with after1, after2;

mixin void after1() {
  super();
  print('after 1');
}

mixin void after2() {
  super();
  print('after 2');
}

This prints:

before 1
before 2
f()
after 1
after 2

A mixin may choose to not call super(...), call it multiple times, or call it conditionally. The signature of super(...) is the same as the surrounding function. A mixin may call super(...) with different arguments than the mixin was itself passed.

In other words, it's like a function has a list of function bodies, with each one determining when the previous one gets called.

It's a compile-time error if:

• The function mixins in a chain don't all have the same parameter signature.

• The first function mixin (which may be the implicit one from the function's own body) contains a super() call since there is no preceding function mixin to call.

Function augmentations

We extend function augmentations to allow a function augmentation to add function mixins before or after the function body. If multiple augmentations add to the same function, then the mixin clauses are added in augmentation application order.

This gives augmentations a way to add code before or after a function, or both. We can probably get rid of the restrictions around "incomplete" and "complete" functions and instead treat augmenting a complete with another function body as a convenience syntax for appending a function mixin of that body.

Ambiguity

The syntax super(...) is already valid syntax inside an instance method for a call to the superclass's call method. This means that applying function mixins to instance methods in a class is ambiguous. Does the super(...) call call the parent function mixin, or the superclass's call method?

Since the latter is rare and can already be expressed using super.call(...), we make a language versioned change and unconditionally interpret super(...) to mean "call the preceding function mixin".

(Tangent: If you are all-in on object-orientation, you might think of a function declaration as syntactic sugar for declaring a singleton instance of an anonymous class with a call() method whose body is the function body. Function mixins would then be actual class mixins on that hidden class. In that case, using super() does make sense to call the previous function mixin because it really is calling super.call() on the mixin superclass.)

[lrhn]

I like the idea.
(If we allow adding the mixin applications from the side, and we have aspect oriented programming! ... So let's not do that.)

It is similar to #4308 in that it allows "overriding" a function and using super to access the overridden version. That issue uses it for augmentation, so that an augmenting foo function can call foo.super(args) to call the augmented function.
You have to declare the override as a separate function declaration inside the same scope, it's not inlined in one function declaration like the with clauses.

What function mixins does better is that it allows reusing a function. It allows abstracting over name.

So you can (probably) do:

mixin Never throwNotMutable([_, _]) { 
  throw UnsupportedError("Not mutable");
}

mixin class UnmodifiableList<T> implements List<T> {
  void add(T value) with throwNotMutable;
  bool remove(Object? value) with throwNotMutable;
  void removeAll(Iterable<Object?> values) with throwNotMutable;
  T removeAt(int index) with throwNotMutable;
}

and use the same function for every method.
I like that. Also related to #2166 (comment), a way to reuse a function declaration.

If we generalize with with before and after, we can also allow multiple bodies:

int foo(int x, int y) with outer {
  doStuffFirst(x, y);
} with middle {
  doStuffLast(x, y);
} with inner;

That avoids having to declare mixin int _fooHelper(int x, int y) { doStuffFirst(x, y); } so you can write it as with middle, _fooHelper, outer;.
A function declaration ends at a } not followed by with, or at a ; following a with clause.
(Could be a little confusing that the mixins are applied last-to-first, not first-to-last like classes. But classes go up the inheritance tree, functions run from start to end. It'd probably be much more confusing if the function code ran in the opposite order.)

Might need some more context constraints on the function if we want it to work with instance methods. Probably an on clause to say which classes it can be an instance member of, so that it can refer to this, ... and maybe super.otherName().

mixin<T> sortReversed([int Function(T, T)? compare]) on List<T> {
  super((T a, T b) => compare(b, a));
}

class ReversedList<E> extends ListBase<E> {
  E operator[](int index) => super[length - index - 1];
  operator[]=(int index, E value) => super[length - index - 1] = value;
  void sort([int Function(E, E)? compare]) { super.sort(compare); } with sortReversed<E>; // Do I need the body?
}

Could get confusing if sortReversed is generic itself.

That does mean that using foo.super(args) is not useful here, because it hardcodes the super-function's name.
So this.super? (Argh! No!)

It would be nice if you can apply a mixin using super(...) even if there is no prior declaration in this class, in which case it goes to the superclass implementation instead. Then you won't need the spurious {super.sort(compare);} body above, and you can also use the reverser as:

class MyReversedList<E> {
   void sort([int Function(E, E)? compare]) {
      bubbleSort(this, compare);
   } with sortReveresed;
}

If the mixin can only use super(...) if it's not the first mixin, then you easily end up with two mixins, one for being first which calls the superclass method, and one for being second which calls the mixed-onto super-function in this class.

(Specification-wise, one can think of instance functions as being chains of implementations, with each class having its own "top impl", and the class can call the top-impl of foo of the superclass using super.foo(...). Function mixins allows a single class to add multiple links in that chain, the last one will be the class's top-impl, but each one can call the prior one using super(). Then there is no gap between classes, the super() of the first declaration of a foo function of a class is the same as the super.foo(), it's just the prior implementation in the chain.)

The syntax super(...) is already valid syntax inside an instance method for a call to the superclass's call method.

Well, crap! Why did we do that? (I'm pretty sure I can blame myself for that in some way, it's exactly the kind of orthogonality I'd argue for.)

I'd be happy to disallow it. If people can figure out to do foo?.call(42) to do a null-aware function invocation, they can surely do super.call(42) in the minuscule number of cases where it would matter.

That was probably why I ended up using memberName.super(args), which is new syntax because super can't be prefixed today. (I want the same kind of syntax for invoking specific super-members of mixin applications, like:

class Foo extends Bar with Baz, Qux {
   @mustCallSuper()
   void init() {
     Qux.super.init(); // aka super.init()
     Baz.super.init();
     Bar.super.init();
   }
}

That would be useful in some cases, and even more if we get composite mixins.)

But that syntax is not useful if you abstract over names, and want to use the same function mixin under more than one name, and have each call its individually named super.

[Wdestroier]

The following code:

mixin Never throwNotMutable([_, _]) { 
  throw UnsupportedError("Not mutable");
}

void add(T value) with throwNotMutable;

Looks very similar to:

Never throwNotMutable([_, _]) { 
  throw UnsupportedError("Not mutable");
}

void add(T value) = throwNotMutable; // Similar to factory X() = Y;

The = sign would work with existing code, but it wouldn't inline throwNotMutable I guess.

[loic-sharma]

I like this proposal a lot if it can be used with augmentations!

I'd be OK with a slightly reduced version of this proposal where function mixins can only be added in one location on the function declaration. Effectively this would be the middleware pattern where calling super calls the next "middleware" in the chain: either the next function mixin or the function itself if the end of the function mixin chain was reached.

Running the mixin function before the function:

mixin void before() {
  print('before');
  super();
}

// Prints:
// before
// hello
void hello() with before => print('hello');

Running the mixin function after the function:

mixin void after() {
  super();
  print('after');
}

// Prints:
// hello
// after
void hello() with after => print('hello');

Mixin functions are executed in order as a stack:

mixin void foo() {
  print('foo - before');
  super();
  print('foo - after');
}

mixin void bar() {
  print('bar - before');
  super();
  print('bar - after');
}

// Prints:
// foo - before
// bar - before
// hello
// bar - after
// foo - after
void hello() with foo, bar => print('hello');

Mixin functions can short-circuit:

mixin void shortCircuit() {
  print('short-circuit');
  // This does not call super()!
}

// Prints:
// short-circuit
void hello() with shortCircuit => print('hello');

[atototenten]

but above all ,whats the point/benefit of this ?

thanks