Improve typings of Array.map when called on tuples

[zroug]

Search Terms

• Array.map
• map tuple

Suggestion

Using Array.map on a tuple should return a tuple instead of an array. In one of my projects I could achieve that using

declare interface Array<T> {
    map<U>(callbackfn: (value: T, index: number, array: T[]) => U, thisArg?: any): { [K in keyof this]: U };
}

I haven't encountered any negative side effects.

Use Cases

This can be useful when you want to use tuples as a fixed length array.

Examples

type Vec3D = [number, number, number];
let vec: Vec3D = [1, 2, 3];
let scaledVec: Vec3D = vec.map(x => 2 * x);

This is currently an error:
https://www.typescriptlang.org/play/#src=type%20Vec3D%20%3D%20%5Bnumber%2C%20number%2C%20number%5D%3B%0D%0Alet%20vec%3A%20Vec3D%20%3D%20%5B1%2C%202%2C%203%5D%3B%0D%0Alet%20scaledVec%3A%20Vec3D%20%3D%20vec.map(x%20%3D%3E%202%20*%20x)%3B

But with the proposed change it would not be an error:
https://www.typescriptlang.org/play/#src=declare%20interface%20Array%3CT%3E%20%7B%0D%0A%20%20%20%20map%3CU%3E(callbackfn%3A%20(value%3A%20T%2C%20index%3A%20number%2C%20array%3A%20T%5B%5D)%20%3D%3E%20U%2C%20thisArg%3F%3A%20any)%3A%20%7B%20%5BK%20in%20keyof%20this%5D%3A%20U%20%7D%3B%0D%0A%7D%0D%0A%0D%0Atype%20Vec3D%20%3D%20%5Bnumber%2C%20number%2C%20number%5D%3B%0D%0Alet%20vec%3A%20Vec3D%20%3D%20%5B1%2C%202%2C%203%5D%3B%0D%0Alet%20scaledVec%3A%20Vec3D%20%3D%20vec.map(x%20%3D%3E%202%20*%20x)%3B

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code (At least I think so...)
• 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. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[DanielRosenwasser]

Duplicate of #12548, was addressed in #11252.

Unfortunately I believe that

1. it potentially broke subtyping arrays (this might not be true)
2. it didn't work for arbitrary arities
3. it and slowed down the compiler a lot

so we reverted it in #16223.

[dragomirtitian]

@DanielRosenwasser The arity problem can be solved now that we can map tuples. Not sure about the performance, but not having a ton of overloads might improve it a bit

interface Array<T> {
  map<TThis extends Array<T>, U>(this: TThis, fn: (v: T) => U): { [K in keyof TThis]: U }
}

function tuple<T extends any[]>(...a: T) {
  return a;
}

let x = tuple(1, 2).map(v => v.toString()); //[string, string]
let o = tuple(1, 2, 3).map(n => ({ n }));

[zroug]

Yes, I opened this issue in light of TypeScript 3.1 mappable tuple and array types. So maybe things have changed?

[dragomirtitian]

Also from what I see #16223 reverted a lot more than just changes to map, it rolled back the preservation of thisArg in the callback on multiple array functions. Inferring this on any array function might incur a significant perf penalty, for something that (at least in my experience) is not all that used (ie thisArg).

This issue requests improve just map this would seem like a wider use case and less of a perf penalty since we are just talking about map and not other array functions.