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 <[email protected]> wrote: > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
