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

Alexander Jones alex at weej.com
Tue Dec 5 23:38:12 UTC 2017


> with the added bonus of transparently allowing sync functions to be
converted to async functions without fundamentally affecting consumer
calling code.

It does fundamentally affect calling code if the calling code reaches
outside of its local variables. The state of the world around you might
change any time you await and give control back to the event loop.

On Mon, 4 Dec 2017 at 19:16, Naveen Chawla <naveen.chwl at gmail.com> wrote:

> Obviously. The whole point of this proposal is that awaiting async
> functions is automatically _implied_ inside an `autoasync` function, unless
> an async function is called with a `background` qualifier (which thereby
> makes it return its promise instead). The OP is right: this is a far less
> bug prone way to do async programming than `async` `await`, while offering
> all its functionality, with the added bonus of transparently allowing sync
> functions to be converted to async functions without fundamentally
> affecting consumer calling code.
>
> For those who want to be able to do extensive async programming, having
> this in the language, and using it instead of `await` `async` throughout,
> is a no-brainer.
>
> Of course, I am qualifying that it must be new keywords, not `await`
> `async` juggled like in the original post, but that wasn't the thrust of
> the proposal anyway.
>
> On Mon, 4 Dec 2017 at 21:09 Isiah Meadows <isiahmeadows at gmail.com> wrote:
>
>> Am I misunderstanding something about this proposal that it's
>> substantially any different from `.then` or immediately invoked async
>> functions?
>>
>> ```js
>> // Original
>> await function foo() {
>>     const bar = async baz()
>>     use(bar)
>> }
>>
>> // What I'm reading
>> function foo() {
>>     ;(async () => {
>>         const bar = await baz()
>>         use(bar)
>>     })()
>> }
>> function foo() {
>>     try {
>>         Promise.resolve(baz())
>>         .then(bar => { use(bar) })
>>     } catch (e) {
>>         Promise.reject(e)
>>     }
>> }
>> ```
>>
>> On Mon, Dec 4, 2017, 09:54 T.J. Crowder <tj.crowder at farsightsoftware.com>
>> wrote:
>>
>>> On Mon, Dec 4, 2017 at 2:37 PM, Bob Myers <rtm at gol.com> wrote:
>>> >
>>> > It turns out that this approach has a number of problems.
>>> > As a result, future versions of selenium will no longer support it.
>>> > Test writers will be asked to write `await` where needed.
>>>
>>> Were there problems other than the complexity of maintaining the
>>> promise manager tool and issues with debuggability? Neither of those
>>> seems like it would be an issue with Steven's proposal...
>>>
>>> (I just realized for the first time, Bob, that your initials are RTM.
>>> I love it. You should adopt Frank as a second middle name. ;-) )
>>>
>>> -- T.J. Crowder
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20171205/b2b45469/attachment-0001.html>


More information about the es-discuss mailing list