Question: is it intentional that the Future class cannot be extended?

[evanweible-wf]

To clarify, you can extend the Future abstract class, but the implementation lives in _Future and type checks are made against that private class. This means that attempting to extend Future does not work with methods using the async keyword since the custom future will not be recognized as a _Future and will then be wrapped in one.

I've seen a similar issue about extending types here: #3888
I understand that there are a list of types that cannot be subclassed for efficiency reasons - is Future one of them? If so, is there any chance that would change?

[lrhn]

Basically, yes: It's for efficiency reasons, and it most likely won't change.

If we can recognize the internal implementation of Future, then we can do more efficient things with it by accessing the internal private fields directly instead of always going through then (which always has at least one extra microtask delay). Working directly on _Future, we can propagate completion results through multiple futures in a single loop.

If the internal Future implementation was the Future class, we couldn't make this distinction. Dart does not allow us to distinguish a class extending Future from one implementing Future (short of using mirrors, which isn't viable), but only the ones that extend Future will inherit the private fields.

I have two recommendations related to this, which are two aspects of "favor composition over inheritance":

• Don't extend the Future interface. The reasons to do so is usually that you want to pass an object that has a future and some further operations around, and you want to pass it through existing functions that expect a Future. That suggests that there is something in your model that doesn't fit. Maybe you can create this other class containing a future and some more, and make your functions expect that instead of Future.
• If you want to extend Future anyway, use delegation. In package:async there is a DelegatingFuture that you can extend, and which will delegate the basic operations to some other future. That should allow you to do whatever it is you want to do.

[mezoni]

@lrhn
It sounds unconvincing.
The implementation of the 'Future' in Dart SDK is not very effective.
Not effective implementation means that they are very slow and consume a lot or memory.

[duzenko]

This is sad
This entire 'special class' concept screams "Dart is slow" like nothing else.
How do I return a DelegatingFuture from an async method?

[lrhn]

You cannot return a DelegatingFuture from an async method because the returned future is created by the method itself, not by you.

If you want to control the returned future, you need to make a non-async function which returns a the future you want. You can always do that, and you can use async helper functions for parts of that.

[duzenko]

I am well aware of that option.
Chaining then's looks ugly and is why await/async exist in the first place.