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

kai zhu kaizhu256 at gmail.com
Thu Dec 7 12:32:19 UTC 2017


> On Dec 7, 2017, at 5:50 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 
> The real solution to that would be stackful coroutines, but those are tricky to implement and are substantially slower at lower nesting levels. (Go's goroutines are built from this under the hood.) There's tradeoffs to be made.

that is never going to happen. unless the goal is to intentionally sabotage javascript’s fundamental-design and cause even greater chaos and instability in the world of frontend-development.

> 
> On Thu, Dec 7, 2017, 05:45 Florian Bösch <pyalot at gmail.com <mailto:pyalot at gmail.com>> wrote:
> as I predicted once you use it, await/async infests all calls/funcdefs, and has now become pointless line-noise that you need to remember to write or you will get into trouble, but serves no discernable semantic, syntactic or logical function other than making you type more.
> 
> solution: write a transpiler that inserts await/async into all calls/funcdefs
> 
> On Sun, 3 Dec 2017 at 12:01, Steven Mascaro <subs at voracity.org <mailto:subs at voracity.org>> wrote:
> Sorry for making this request now (rather than when async/await was first being formulated), but real-world use has led me to think some things could benefit from a slightly different syntax. I also apologise if this has been raised/discussed before, I wasn't able to find it. The proposal is most quickly explained with an example.
> 
> Current:
> 
> class RemoteService {
>     async init() { ... }
>     async setProp(id, val) { ...; return this }
>     async getProp(id) { return ... }
>     async runInBackground() { ... }
> }
> 
> async function remoteExample() {
>     let remote = new RemoteService();
>     await remote.init();
>     await (await remote.setProp('a', 1)).setProp('b', 2);
>     remote.runInBackground();
>     let val = await remote.getProp('a');
>     return val;
> }
> 
> Proposed:
> 
> class RemoteService {
>     await init() { ... }
>     await setProp(id, val) { ...; return this }
>     await getProp(id) { return ... }
>     await runInBackground() { ... }
> }
> 
> await function remoteExample() {
>     let remote = new RemoteService();
>     remote.init();
>     remote.setProp('a', 1).setProp('b', 2);
>     async remote.runInBackground();
>     let val = remote.getProp('a');
>     return val;
> }
> 
> Why:
> 
> Running things in a genuinely asynchronous way is actually *unusual*. The current async/await syntax (which I think should still stay) is the exact reverse of what fits the probable use cases. Missing the 'await' keyword (particularly on functions/methods that don't return a value) causes all sorts of hard to track down bugs. I myself didn't realise this until I (and others I work with) started making intense use of async/await.
> 
> The new proposed syntax above is obviously much simpler and would be very hard to get wrong. By contrast, the original syntax has proven surprisingly difficult to get consistently right. Even now with quite a lot of practice, I'm occasionally forgetting an await here and there. In addition, patterns like chaining get ugly *very* quickly. (Although I guess that could also be fixed with a method-friendly async call syntax.)
> 
> If the proposed syntax were available in addition to the current syntax, you could apply whichever keyword in the function declaration is most likely applicable at call sites. e.g. runInBackground could be declared 'async' rather than 'await', if you normally expect it to be run in the background.
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> 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/20171207/528ea009/attachment.html>


More information about the es-discuss mailing list