Future<T> type improvements

[laverdet]

I recommend adding an overload in Future like this: resolve(): Future<void>;

This will make it so that Future.resolve() is a valid invocation which returns a Future<void>.

Additionally, the default type on the Future.halt<T> generic should be changed to never. This can be demonstrated with this quick example:

declare const calculate: () => number; // May throw
function execute() {
    try {
        return Future.resolve(calculate());
    } catch {
        return Future.halt();
    }
}

This will make it so that the return value of this function is Future<number> instead of Future<unknown>. I think this makes sense in practice because the value of the halted future should be impossible to observe.

[cowboyd]

@laverdet Thanks for reporting!

It should be safe to add the overload to Future.resolve() since it is currently impossible to call Future.resolve() without saying Future.resolve<void>() right? As far as I can tell, all existing code should still work.

However, the change to Future.halt() would have to wait for v3. I'm hoping to create a roadmap for effection in the next couple of weeks to include changes / deprecations for v3 and v4.

[cowboyd]

The v3 API for Future has been grossly simplified so it is no longer capable of representing a halted computation. In effect, it is exactly like a Promise that may or may not resolve synchronously, and can both be yielded to, but also awaited

In fact, because the v3 API has been so drastically simplified, there isn't really any need to construct futures yourself anymore.

Thank you so much for reporting this issue. It was very helpful in forming the v3 API, and I think we arrived at a great place in the end.