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