await on synchronous functions

[Dean Landolt]

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

> > 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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150726/6c771ceb/attachment.html>