Type parameter constrained to an array is not indexable by `${number}`

[Andarist]

🔎 Search Terms

parameter constraint array index indexable number template literal

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.4.0-dev.20231218#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwxAGcMBGAHgEF4QAPQ1YI+NAa1RwHdUBtAXQB8AClgwAXPEoBKCZR6pkAWwBGIGHwDcAKFCRYCFOmx4CxDACYqNeiEbM2Hbv2GjZMyTwAGAEgDeClTUAX09NIA

💻 Code

declare function test1<A extends unknown[]>(arr: A): A[number];
declare function test2<A extends unknown[]>(arr: A): A[`${number}`];

🙁 Actual behavior

test2 is an error

🙂 Expected behavior

I expect both to be roughly identical - both should not error here.

Additional information about the issue

I think that this should be OK since #48837:

• 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.

[RyanCavanaugh]

Is there a userland report of this? I'd prefer to wait on a PR if not

[ssalbdivad]

@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:

1. TS uses number for all indices and literals like "1", "2" etc. for tuple literal keys
2. When accessing a value in runtime code, it lets you substitute the numeric literal for the string literal
3. 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.

[Andarist]

Isn’t this issue an userland report? 😅