Skip to content

Allow annotations inside the head of a for...in statement #25605

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

Closed
4 tasks done
todor2810 opened this issue Jul 12, 2018 · 2 comments
Closed
4 tasks done

Allow annotations inside the head of a for...in statement #25605

todor2810 opened this issue Jul 12, 2018 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@todor2810
Copy link

Unlike element in for (let element of iterable) {} and error in try {} catch (error) {} where element and error are determined at run-time, key in for (let key in object) {} is already known to be a string at compile-time.

I propose we accept an annotation for key. In other words, the following syntax should be valid:

for (let key: string in object) {}

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. new expression-level syntax)
@mhegazy
Copy link
Contributor

mhegazy commented Jul 12, 2018

string is not accurate here the correct type is Extract<keyof typeof obj, string>. Given that the possible types allowed here are limited, allowing an explicit type annotation seems more noise than value.

Please see #3500 for related discussion.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 12, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants