-
Notifications
You must be signed in to change notification settings - Fork 106
Top level awaits #36
Comments
We specifically reserved |
Oh, cool, thank's for the response. |
We're probably not ready for this yet, but for the record there are two solutions that make sense to me: For server-side systems, it makes sense to me to have a Also, if we ever get do-expressions, then it would makes sense to also have a do-async-expression. do async {
let x = await a.doStuff();
let y = await a.doOtherStuff(x);
} My personal opinion is that we should not allow modules themselves to be async, for simplicity and separation of concerns. Also, I don't think we want to outright reject the possibility of a system which loads modules synchronously and doesn't need to worry about async within the module system itself. |
Note that there is also quite a bit of discussion on this same topic in #9. I'll close this issue to keep a single thread of discussion on top level await. |
Is there any notion or plans for such thing? In Node we use
doSomeStuffSync
in global (module) space, where concurrency isn't required and order of commands really matters.But global-space
await
s could obsolete thoseSync
-suffixed functions and open the possibility to remove them entirely.Of course, if
a.doOtherStuff
accepts promises it may be implemented on usual async versions, but if it's not (most of today's API), we'll have an option. I'm not sure about technical possibility for this, just asking. But this have special benefits likeThe text was updated successfully, but these errors were encountered: