Mapped types over subclassed arrays behave strangely

[Andarist]

🔎 Search Terms

mapped type array subclass numeric constraint

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.6.0-dev.20240712#code/MYGwhgzhAEDKCuAjAggJ1WAngHgCoD5oBTADwBciA7AExjQxwOgG8BYAKGmnAjIAV4EABZFqALmjwaRAGYBLSqOgAfaLgDcHAL4cOZTAAciaorzzFyVWtABKRMNQD2lEJnpZsYSpnyEAvCwcXADaANLQCtAA1kSYjjJqALoSuGGJmuxaGXqGxnYQ8CBk0AG4pmTYCCjoHpTwALaIRKi+GQD0bVzQAHoA-DlG0ALCJbamhWTBAEQGgkJT6RwdXX1AA

💻 Code

class SubArray<T> extends Array<T> {
  lastPushed: undefined | T;
}

type Test<T extends ReadonlyArray<any>> = {
  [K in keyof T]: T[K];
};

type Result = Test<SubArray<number>>;
//   ^?
type Push = Result["push"];
//   ^?

🙁 Actual behavior

This mapped type doesn't have a homomorphic instantiation - its arrayness is not preserved. But yet all members are mapped to the Array's type argument

🙂 Expected behavior

I'm not entirely sure. On one hand, it feels that those members should be instantiated with the type of the original member. This wouldn't work with generic mapped types as T[K] has the numeric constraint when T has an array/tuple constraint. So the generic constraints wouldn't match what those could end up being instantiated with.

Should the result be a remapped subclassed array? That means that extra members wouldn't be mappable... but hey, regular array methods etc arent. So perhaps that's the most appropriate solution here.

cc @ahejlsberg

Additional information about the issue

No response

[ahejlsberg]

Hmm, yeah, the behavior here is odd, but it's not immediately clear how to fix it.

In the Test mapped type, K is given the contextual constraint number | `${number}` because T is constrained to an array or tuple type (see #48837). That in turn means that the T[K] is resolved as T[K & (number | `${number}`)]. When we instantiate with SubArray<number> for T and "push" for K, we get SubArray<number>[never], which comes out as number (you could argue it should be never, but that wouldn't really help any).

The logic error here is that we take the array constraint for T in Test to mean that T will always represent an actual array or tuple type (and not some type derived from an array type), but then in the mapped type instantiation we only map to an output array or tuple type when the input is an actual array or tuple type.

We could potentially detect that the mapped type is instantiated for a derived array type and attempt to create an instance of that type for the mapped element type. But it starts to get speculative and would only work when the derived type passes the type parameter straight through.