ES2016 meta property suggestion: function.promise to access an asynchronous function's implicit promise

[UltCombo]

When working with async functions (through Babel), I sometimes face use cases where it would be desirable to get a reference to the currently running async function's promise (e.g. to store the reference in a lexical binding).

Currently, it looks like I have to split the async function in two functions in order to store the return value (a reference to the promise) of an async function, which often results in ugly code.

Hence, I propose a new function.promise meta property which resolves to the currently running async function's underlying promise. I'd like to know whether this sounds feasible before working out the details of the proposal.

@lukehoban @allenwb WDYT?

[bmeck]

Can we make this more generic if https://github.com/jhusain/compositional-functions happens it might not be a promise

[Jamesernator]

I could imagine something similar for Generators and AsyncGenerators like function.generator, perhaps a generic function.context which is whatever the function actually returned (for async functions this would be promises, for generators the generator object, for compositional functions the Task, Thunk, whatever).

[UltCombo]

I'm not sure about generalizing those. I liked the idea at first, but there are a few problems.

First, "context" is an overloaded word: when JavaScript developers hear the word "context", some think about the running execution context's LexicalEnvironment, others think about the running execution context's LexicalEnvironment's EnvironmentRecord's this binding. It is true that there is no proper definition of "context" in the ES public APIs yet, but the word is too generic and will likely add to the confusion.

I believe more explicit terms such as function.promise and function.iterator are more user-friendly. The resulting code will be more readable, and if applied in the wrong context they may throw errors instead of returning unexpected values—think function.promise inside a generator or function.iterator inside an async function: these may throw and fail loudly, while a generic approach may fail silently.

edit: grammar

[UltCombo]

And the other problem is that you will hardly find a word that is generic enough to cover all the suggested use cases and that still holds any meaning. Perhaps function.implicitReturnValue or function.underlyingObject, but those are too verbose and not as practical and concise as the single-word single-purpose meta properties I've suggested.

[Jamesernator]

Yeah you're right, and actually thinking about it an Async Iterator has both an implicit promise (which is constantly changing) and an iterator.