Enable async/await to work on functions that don't just return promises.

Mark mark at heyimmark.com
Sun Feb 26 23:52:29 UTC 2017

Codefined, just out of curiousity, do you have anything to do with this
proposal that got announced today
<https://github.com/tc39/proposals/pull/41>? Or is it just a coincidence? :)

On Sun, Feb 26, 2017 at 3:07 PM Dean Tribble <tribble at e-dean.com> wrote:

> Should `callee()` be asynchronous here?  To my mind, no, it shouldn't.
> Every single line here is synchronous, so the function itself should surely
> be synchronous.  Shouldn't functions that may not have `await` in them, but
> instead that are actually asynchronous and hence use the `async return`
> keyword be the ones we define with `async`?
> In the Javascript (and Midori) model, concurrent execution of multiple
> activities is achieved by breaking those activities up into coarse-grained,
> application-defined "turns" (or "jobs") and interleaving those.  An async
> boundary is where the current turn could end, and the turns for other
> concurrent activities might run, changing the state before the current
> activity proceeds.
> Therefore, callee must be async, because that declares that there could
> be a turn boundary within it, and thus, the rest of the state of the
> program could change as a result of the call.  The caller of callee *must
> *ensure that it's invariants are correct before allowing other code to
> interleave with it.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170226/62dc695d/attachment.html>

More information about the es-discuss mailing list