When should we define a function as async

Benjamin Gruenaum benjamingr at gmail.com
Wed Jun 3 10:08:05 UTC 2015

> If you want a special Promise (subclass or extended), you should not use
async function since it casts the return value to a standard Promise

Right, there was a proposal that let you override how await works (
https://github.com/jhusain/compositional-functions) but I don't think it's
currently actively persued (Jafar, feel free to correct me here).

> If you want to return a promise and attach callbacks to it (not returning
promise that spawns by then), you should not use async

This is also correct.

>  it’s quite hard to determines if one method is actual async (with
Promise) or sync (immediately return values), so I may preferr to mark all
async function async for better read experience

I don't think the distinction is correct. For the consumer - it is
irrelevant if a function is async or just returns a promise. If you're
writing an API and your function _sometimes_ return promises it is best to
make them always return promises - more generally if a function is
sometimes asynchronous (with callbacks too) it should always be

> Never write return await xxx;, it seems useless either xxx is a promise
or not

Yes, unless of course you're also doing other things inside the function.

> Anyway this is not an issue about spec itself, it’s more like an open
discussion, thanks for reply :)

Correct - I'm in no position to tell you what you can and cannot do but in
the future I think it is best to ask these questions in Stack Overflow, IRC
and on discussion groups. If you have issues about style, usage or anything
else that is not the spec it is best to keep them off esdiscuss which is
quite a noisy list anyway :)

Feel free to send me an email (rather than the whole list) if you have
other issues with `async` that are not spec related.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150603/90fd8820/attachment.html>

More information about the es-discuss mailing list