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

Isiah Meadows isiahmeadows at gmail.com
Thu Dec 7 10:50:38 UTC 2017


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.

On Thu, Dec 7, 2017, 05:45 Florian Bösch <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> 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
>> 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/ef93629f/attachment.html>


More information about the es-discuss mailing list