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
m...@isiahmeadows.com
On Sat, Feb 25, 2017 at 5:55 PM, Codefined <codefi...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
