async/await -> await/async: a simpler, less error-prone async syntax

Naveen Chawla naveen.chwl at
Mon Dec 4 05:38:17 UTC 2017

The crux of your idea is: let any calls of an async function inside an
async function automatically await unless explicity instructed to run "in
the background". I like the idea. I just wouldn't use the words "await" and
"async" for it, because they are used as currently in C#.

On the last disagreement by T.J Crowder: 1. it's an alternative (perhaps
with different words), not necessarily in conjunction with the existing
syntax. 2. The promise would be accessible via e.g. `const promise = background
remote.runInBackground();` 3. If a presumption is made that in an async
function, other async function calls are automatically awaited unless
prefixed with `background`, I'm not sure about the value of having a "clear
indicator" of which function calls are sync and which are async - in normal
use I wouldn't care. I just want their results and if I want to make a
function async (by adding a server call, etc.), I can do so transparently
without breaking my code. I agree with the thrust of this proposal.

The horse has bolted on `await` `async`, but maybe with different keywords,
e.g. `asyncauto` and `background`, I would definitely use this new syntax
instead of `await` `async` (which I use currently), for the reasons stated
in the original post. Bug minimization is a big factor in the features I
use, and should be THE driving factor in introducing new features.

The OP has stated this idea upon extensive real world use, and I appreciate
that. I would definitely support the introduction of e.g. `asyncauto` and
`background`, and would definitely use it immediately in all cases instead
of `async` `await` if introduced.

On Sun, 3 Dec 2017 at 17:13 T.J. Crowder <tj.crowder at>

> I understand the motivation, but I have to disagree with the proposal
> for multiple reasons:
> 1. It adds too much confusion to the existing syntax.
> 2. If the calling code needs to call one of these new-style `await`
> functions and access its promise (rather than `await`ing it), it
> doesn't have a way to do that; `async`/`await` doesn't have full
> coverage of all patterns (yet, possibly never), sometimes you still
> need to access the actual promise (for instance, to feed into
> `Promise.all` or `Promise.race`). (Obviously you could add something
> to make it possible to access the promise.)
> 3. Having a clear indicator in the source saying where the async
> boundaries are is useful for code correctness. With the new syntax, I
> have no idea of the temporal sequence of this code:
> ```js
> let x = foo();
> let y = bar();
> ```
> ...without going and looking at the declarations of `foo` and `bar`.
> With current syntax, it's clear when there's an async break in the
> flow. I think the phrase is "prefer explicit to implicit" or something
> like that.
> -- T.J. Crowder
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list