await on synchronous functions

Dean Landolt dean at
Mon Jul 27 03:42:16 UTC 2015

On Sun, Jul 26, 2015 at 8:07 AM, Benjamin Gruenbaum <benjamingr at>

> > Out of curiosity, can you give an example of the Not Good parts? ISTM
> the await prefix is more of an explicit cast than an implicit conversation,
> and other than the very small timing gap in how throws are handled I
> pointed out a few days ago, I can't think of any situations where a throw
> would make more sense than casting values to promises.
> Sure, lots of such cases exist today with promises and are easy to
> reproduce
> ```js
> async function foo {
>     let result = await bar; // instead of bar();
>     let result2 = await callbackFn(); // await on function that was not
> "promisified yet", that is, it takes a callback
>     let result3 = await [p1, p2, p3]; // people might expect a Promise.all
> on an array, but this doesn't actually wait for anything.
> }
> ```

The first example is a basic type error, not at all specific to promises or
async programming -- it could be made any number of ways. If you want to
call it a footgun, that's fine -- but ISTM the only real solution is "use
TypeScript" (or some analog).

I don't see how the last example could possibly exist today as it reflects
a hypothetical user's misunderstanding of `async/await` syntax
specifically. Perhaps there's a case to be made that there's a footgun here
(though I'd disagree), but it's beside the point of this thread.

But the second example, `await callbackFn()`, seems reasonable. I still
think it would be a shame to punt on otherwise elegant ergonomics just due
to this, but I buy that there's at least some benefit now.

I suppose it'd always be possible to introduce something like
`await.resolve` if there's demand for this kind of sync/async normalization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list