Skip to content
This repository has been archived by the owner on Feb 2, 2023. It is now read-only.

Top level awaits #36

Closed
ivan-kleshnin opened this issue Mar 9, 2015 · 4 comments
Closed

Top level awaits #36

ivan-kleshnin opened this issue Mar 9, 2015 · 4 comments

Comments

@ivan-kleshnin
Copy link

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.

// this is global space
let x = a.doStuffSync();
let y = b.doOtherStuffSync(x);  

But global-space awaits could obsolete those Sync -suffixed functions and open the possibility to remove them entirely.

// this is global space, no "async" function wrapper
let x = await a.doStuff(); 
let y = await a.doOtherStuff(x); 

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 like

let x = await a.doStuff(); 
console.log(x);
// vs
let x = a.doStuff().then(function(v) { console.log(v); return v; }); 
@domenic
Copy link
Member

domenic commented Mar 9, 2015

We specifically reserved await at top-level in modules to account for this possibility. Nobody's had the time to really figure out the semantics yet, though.

@ivan-kleshnin
Copy link
Author

Oh, cool, thank's for the response.

@zenparsing
Copy link
Member

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 main function which defines program entry. If the executed module exports a main function, then it would run that. The main function could be an async function.

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.

@lukehoban
Copy link
Collaborator

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants