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

Codefined codefined at debenclipper.com
Sun Feb 26 10:59:01 UTC 2017

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>

More information about the es-discuss mailing list