Enable async/await to work on functions that don't just return promises.

Isiah Meadows isiahmeadows at gmail.com
Sun Feb 26 00:14:41 UTC 2017

Here's my thoughts:

1. There's minimal benefit to be gained with your example, since it
can already be simulated very similarly with the current API:

function asyncFunction() {
    return new Promise(resolve => {
        someAsync('data', (...args) => resolve(args))

2. This won't alleviate you of the need to learn promises anyways, and
in general, when you're working with async code, you *should* learn
the Promise APIs. Otherwise, `async` functions won't make much sense
to you, and you're liable to forget an `await` when you needed one.

3. The concepts aren't really that complicated. It's already easy to
explain as an asynchronous `return` or `throw`, just they aren't
syntactic at the start because you can't return from a function in a
callback.[1] You don't have to explain monadic `join` or `bind` just
to explain how a promise works.

[1] Kotlin is an exception here, in that it allows explicitly
non-local jumps, provided they're correctly typed.


Isiah Meadows
me at isiahmeadows.com

On Sat, Feb 25, 2017 at 5:55 PM, Codefined <codefined at debenclipper.com> wrote:
> It strikes me as an interesting development to see that the current
> definition of Async/Await (as I see it), is just simple syntactic sugar for
> `.then()`.  While I, to an extent, see the point of such a command as being
> useful, I remain unaware of the exact reasoning why we need to include
> promises in the first place.  Wouldn't it be so much more powerful to be
> able to use completely normal syntax, as you would in synchronous code as
> well as the option of promise chains?
> For example, take the following code snippet:
> async function asyncFunction() {
>   return new Promise((resolve, reject) => {
>     someAsync('data', (err, data) => {
>       if (err) {
>         reject(err); return;
>       }
>       resolve(data);
>     });
>   });
> }
> This seems to be so very confusing for anybody new studying this language,
> almost everyone I talk to gets stuck up on some part of it.  Wouldn't it be
> so very beautiful if we could just do:
> async function asyncFunction() {
> someAsync('data', (err, data) => {
> async return [err, data]
> })
> }
> When we call this with the `await` keyword, we simply `await` a return.  No
> special promises or extra keywords needed, everything works as you would
> expect it to.  This also has the benefit of shortening our required code
> from 10 lines to 5 lines, removing a significant proportion of boilerplate
> code.
> async function asyncFunction() {
> let [err, data] = await asyncFunction()
> }
> Some interesting counterpoints to consider from the #node.js channel on
> freenode
>  - "Doesn't this just add complexity to the specification?"
>    + Yes, it does mean that people who wish to implement Javascript will
> have to spend longer implementing await/async.  However, in my opinion it's
> a better solution that forcing everyone who wishes to use async/await to
> also learn how to use `new Promise()` and what the `reject()` and
> `resolve()` do.  Due to how often you have to deal with asynchronous code in
> Javascript, often people come across this issue very early on in learning
> the language, making is as easy as adding an extra `async` before your
> return statement seems like an acceptable exchange.
>  - "Why not just automatically promisify functions using a library like
> bluebird?"
>    + Similar to the previous question, I honestly feel that forcing people
> to learn the API for yet another library in order to be able to do such a
> simple task is much more taxing than in this method.
>  - "I just don't like the async return"
>    + Originally it was just a return, but a friend pointed out this ran into
> issues that it would simply return from the last function.  What I thought
> would be much easier was some sort of keyword that makes it return from the
> async function, instead of any other functions.  To me, `async` came
> naturally, but this is just my first suggestion on the future of Javascript,
> and I'd be interested to know if you have any better suggestions.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list