-
Notifications
You must be signed in to change notification settings - Fork 4
CS2 Discussion: Features: Shorter syntax for defining promises and async/await #60
Comments
Good question, I have a couple too... are |
I was thinking about that as well. The issue is that what if there are some nested normal functions defined inside of a |
Under your proposal, every function resolves doesn't it? |
No, why would it? |
If all functions are async, all functions must resolve, no? |
@mitar: I really like your proposal for promises, especially since this is a very common paradigm!
By default I think we should avoid adding keywords like async/await for every function as a default. Perhaps we can split each of these feature requests into it's own issue? |
Or reject, which then |
Migrated to jashkenas/coffeescript#4953 |
I believe CoffeeScript could have a simpler syntax to use async/await. With #10 and jashkenas/coffeescript#3757 initial support for that was merged in, but I think more could be done.
Here are some my previous thoughts on the subject, but here I am proposing another iteration of those thoughts.
I see three issues with current async/await and promises state in JavaScript:
new Promise (resolve, reject) =>
hellasync
keywords automatically to functions if they useawait
, but then it is harder to know when should one call a function withawait
)await
keywords aroundTo address the point 1. I would suggest the
~>
operator for defining functions which return a promise:Would be compiled into:
I am not sure if
~>
should bindthis
or not, I think it probably should inside another function, and not for class methods.resolve
andreject
would be forbidden to define by the developer inside~>
function. Callingresolve
orreject
always returns. If you do not want to do that, you should usenew Promise
manually.If you simply want to create a promise, and not a function which returns a promise, you can do:
So
google
now is a promise with content of Google's home page.The reason why
~>
is a function which returns a promise and not just returns a promise is so that it is clear that it does not call start the promise, but that you have to call it, to start it. But we could also use~>
as a shorthand fornew Promise
only.Anyway, we still have
await
all around the code. For that I suggest we further extend?
operator. We already use it to be able to say "if this is a function, call it", we can also say "if this is a Promise, await it".Currently, the following:
fetch?()
Gets compiled into:
And I suggest it gets turned into:
The side-effect of this change would be that using
?
in a function would make then all functionsaync
? Hmm. Maybe we need another symbol for this. But I would love to have a symbol which would call a function asawait
with something shorter thanawait
.I really think caller should not care how is a function implemented. So that they can just call a function and get the result, async or not.
What would be a drawback of making all functions async?
The text was updated successfully, but these errors were encountered: