You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Type parameter constrained to an array is not indexable by ${number}Β #56823
Numeric index signatures apply when the index type is ${number}. For example `Foo[][`${number}`] resolves to Foo instead of being an error. This is consistent with our existing rule that index signatures apply when the index type is a numeric string literal. For example Foo[]['0'] already resolves to Foo.
changed the title [-]Type parameter constrained to an array is not indexable by `` `${number}` ``[/-][+]Type parameter constrained to an array is not indexable by `${number}`[/+]on Dec 18, 2023
Ryan Cavanaugh (@RyanCavanaugh) I know I've frequently run into problems in this area. They mostly manifest when using generics with tuples. This is my mental model as of today:
TS uses number for all indices and literals like "1", "2" etc. for tuple literal keys
When accessing a value in runtime code, it lets you substitute the numeric literal for the string literal
Counterintuitively, keyof a fixed-length tuple includes number, which both allows access for keys that are known to be out of bounds and prevents corresponding literals like the number 1 from being included in the results.
I'm not sure how much of this would possibly be in scope for this issue, but honestly anything that makes numeric keys accesses behave more consistently would be extremely welcome. It's a very easy mistake to make at a type-level that doesn't reflect any semantic difference at runtime.
Activity
[-]Type parameter constrained to an array is not indexable by `` `${number}` ``[/-][+]Type parameter constrained to an array is not indexable by `${number}`[/+]RyanCavanaugh commentedon Dec 20, 2023
Is there a userland report of this? I'd prefer to wait on a PR if not
ssalbdivad commentedon Dec 20, 2023
Ryan Cavanaugh (@RyanCavanaugh) I know I've frequently run into problems in this area. They mostly manifest when using generics with tuples. This is my mental model as of today:
numberfor all indices and literals like"1","2"etc. for tuple literal keyskeyofa fixed-length tuple includesnumber, which both allows access for keys that are known to be out of bounds and prevents corresponding literals like the number1from being included in the results.I'm not sure how much of this would possibly be in scope for this issue, but honestly anything that makes numeric keys accesses behave more consistently would be extremely welcome. It's a very easy mistake to make at a type-level that doesn't reflect any semantic difference at runtime.
Andarist commentedon Dec 20, 2023
Isnβt this issue an userland report? π