Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow top-level await in namespaces #53715

Open
5 tasks done
TheCymaera opened this issue Apr 9, 2023 · 4 comments
Open
5 tasks done

Allow top-level await in namespaces #53715

TheCymaera opened this issue Apr 9, 2023 · 4 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@TheCymaera
Copy link

Suggestion

πŸ” Search Terms

Top, level, await, namespace, export

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Allow top-level await in namespaces.

Current behaviour:

// ok
await 1;

export namespace Example {
	// not ok
	await 1;
}

πŸ“ƒ Motivating Example

Current:

export const _keyValuePair = await idbKeyValuePair.load("name");
export namespace storage {
	export const keyValuePair = _keyValuePair;
}

πŸ’» Use Cases

export namespace storage {
	export const keyValuePair = await idbKeyValuePair.load("name");
}
@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Apr 10, 2023
@RyanCavanaugh
Copy link
Member

Namespaces turn into IIFEs, so to support this we'd need something like an async namespace keyword sequence and a lot of associated machinery.

@TheCymaera
Copy link
Author

Could you simply await the IIFE?

await (async (myNamespace) => {
    // init namespace asynchronously
})(myNamespace || (myNamespace = {}))

@Josh-Cena
Copy link
Contributor

This would have a lot of feature overlap with the module declaration proposal (since modules are also async by nature). I suggest waiting for that instead of inventing more non-ES features.

Namespaces cannot accommodate top-level await without introducing a new async namespace declaration, because their evaluation must be synchronous. Alternatively you could say: "a namespace decl with no TLA creates a plain object; a namespace decl with TLA creates a promise that resolves to the namespace object", but that will play very poorly with declaration merging and state of Zalgo, etc. etc.

@fatcerberus
Copy link

state of Zalgo

I love that what started as a random reference to the Zalgo meme has become enough of a de facto point of discussion of promises/async that we are now quantifying it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants