-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Computed property names are const contexts #46464
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
Conversation
By analogy with the existing rule that element access argument expressions are a const context. Fixes #45798
This likely shouldn't go into 4.5. Let's discuss at a design meeting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This, or something like it, was originally one of the changes we had slated to go out with template literal types as a whole, but held back on it to reduce potential breakage. I still think it's a good idea. Question, though; as-written, does this make an unannotated object with a computed name get a template literal indexer rather than a string indexer? Eg,
export const a = (thing: string) => ({[`some-${thing}`]: "whatever"});
and if so, do we want that?
@typescript-bot dt test this |
@typescript-bot run dt |
No, although I don't understand why.
I don't think so, but I don't have a strong opinion either way. |
@typescript-bot pack this |
Hey @sandersn, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
No new failures in DT. |
From the design discussion today, we think this is a fine change to make, but will result in such a small improvement that it's not worth the churn. In particular, it fixes the precise repro from #45798, but I doubt that it fixes the original code since nobody is likely to write literal numbers in a template literal slot. |
By analogy with the existing rule that element access argument expressions are a const context. This is useful for template literals, which otherwise have type
string
by default.For example, from #45798:
The problem in #45798 is that
person-${1}
is intended to be checked against the index signatureperson-${Person["id"]}
. But it gets the typestring
, which makes it a late-bound property. With a template type literal, it is instantiated as a string literal and is no longer late-bound.There are a couple of ways that seem best to fix this:
I don't consider (3), making all template literals produce template literal types, because I still believe the common case is that both string and template literals are intended to be widened to
string
.Fixes #45798