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

[Codefined]

Hello Isiah,

I'm not sure you understand my point on why this is important.  Although if you understand all the concepts used here it's logical, it's very intimidating to a person newer to Javascript.  This could be especially true in a framework like Node.JS, where you can run into a situation like this in your first program (for example, reading/writing to a file using promises).  Take:
function asyncFunction() { return new Promise(resolve => { someAsync('data', (...args) => resolve(args)) }) }
Here you have to explain the concept of returning a promise, anonymous functions, array decomposition and what resolving does.  Remember that this could be required to just write to a file. However, if one was to explain:
function asyncFunction() { someAsync('data', data => { async return data }) }
Then one only has to talk about anonymous functions and how `async return` works.  You say in your second point you'll need to learn promises anyway, but you can delay learning about them for a very long time.  I'm struggling to think of a simple program that requires the use of promises over this syntax.  People are able to use things without needing to know how the internal components.  For example, I don't know even vaguely how `bcrypt` works under the surface but I still use it in almost every project I work on.  I'm sure you can think of similar examples where you don't know the exact implementation of something but still use it often without forgetting the necessary syntax (like `await`)..

And I'm afraid I have to completely disagree with your third point.  The concepts are very complicated to a beginner, especially considering how many different concepts you have to learn at once within just your first couple of programs.  We're talking about learning 3-4 new concepts things in just 5 lines of a program that wouldn't be out of place as the third or fourth program you wrote.
On 26/02/2017 00:15:14, Isiah Meadows <isiahmeadows at gmail.com> wrote:
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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170226/b9b9560b/attachment-0001.html>