Mapped tuple types

[jscheiny]

Search Terms

generic mapped tuple types overrides

Suggestion

The syntax here is up for debate, but the basic idea is to be able to apply the idea behind mapped object types to tuples. I would suggest the following:

type MappedTuple<T extends any[]> = [F<E> for E in T];

This would apply a type mapping to each of the element types of the tuple.

For example:

type PromiseTuple<T extends any[]> = [Promise<E> for E in T];
type T1 = Promise<[number, string, boolean]>;
// [Promise<number>, Promise<string>, Promise<boolean>]

Use Cases

This would make it much easier to write functions that take a variable number of arguments that all have to conform to some form and be able to reference the underlying type. This eliminates the need to write a ton of overrides:

all<T>(values: (T | PromiseLike<T>)[]): Promise<T[]>;
all<T1, T2>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>]): Promise<[T1, T2]>;
all<T1, T2, T3>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>, T3 | PromiseLike<T3>]): Promise<[T1, T2, T3]>;
all<T1, T2, T3, T4>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>, T3 | PromiseLike<T3>, T4 | PromiseLike <T4>]): Promise<[T1, T2, T3, T4]>;
...
all<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>, T3 | PromiseLike<T3>, T4 | PromiseLike <T4>, T5 | PromiseLike<T5>, T6 | PromiseLike<T6>, T7 | PromiseLike<T7>, T8 | PromiseLike<T8>, T9 | PromiseLike<T9>, T10 | PromiseLike<T10>]): Promise<[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]>;

Examples

The basic usage of this would be as follows:

type TypeMap<T> = { wrap: T };
type MapTuple<T extends any[]> = [TypeMap<E> for E in T];
type T2 = MapTuple<[number, string, ...boolean[]]>
// [{ wrap: number }, { wrap: string }, ...{ wrap: boolean }[]];

There are many compelling examples of how this would simplify library code. For example, above, instead of having 10 overrides for Promise.all, we could define it simply as:

type PromiseLikeTuple<T extends any[]> = [E | PromiseLike<E> for E in T];
all<T extends any[]>(...values: PromiseLikeTuple<T>): Promise<T>;

Similarly RxJS' combineLatest would similarly benefit (Note: I've moved the project argument to the head of the list because rest arguments must appear last, this differs from the current definition of combineLatest)

type ObservableTuple<T extends any> = [ObservableInput<E> for E in T];
combineLatest<T extends any[], R>(project: (...values: T) => R, ...observables: ObservableTuple<T>): Observable<R>;

This is especially useful because there are only 6(?) overrides for combineLatest meaning that providing 7 or more observable inputs would mean that your types would no longer be strict.

Currently

I don't believe that it is possible to construct a mapped tuple type currently. This would be made possible with the addition of recursive generic types and made easy to use with the addition of generic generic type arguments:

// Currently possible
type Head<T extends any[]> = T extends [infer U, ...any[]] ? U : never;
type Tail<T extends any[]> = ((...args: T) => void) extends (head: any, ...tail: infer U) => any ? U : never;

// Currently errors
type SpecificMapTuple<T extends any[]> = [F<Head<T>>, ...SpecificMapTuple<Tail<T>>];
type GenericMapTuple<F<~>, T extends any[]> =[F<Head<T>>, ...GenericMapTuple<F, Tail<T>>];

function all<T extends any[]>(...values: GenericMapTuple<PromiseLike, T>): Promise<T>;

Note: I think adding this functionality via recursive generic types and high order generic type arguments is probably a more flexible and elegant solution that will enable even more interesting typings but it would be nice to have both of those and the mapped tuple types above.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• 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. new expression-level syntax)

[mattmccutchen]

FWIW, here's the closest I think we can come today, using my favorite encoding of higher-kinded types (which maybe I should release as a library). We need to write as many cases for MapTuple as we think we'll ever need, but then the boilerplate to apply MapTuple to a given mapping is reasonable.

const INVARIANT_MARKER = Symbol();
type Invariant<T> = {
  [INVARIANT_MARKER](t: T): T
};

interface TypeFuncs<C, X> {}

const FUN_MARKER = Symbol();
type Fun<K extends keyof TypeFuncs<{}, {}>, C> = Invariant<[typeof FUN_MARKER, K, C]>;

const BAD_APP_MARKER = Symbol();
type BadApp<F, X> = Invariant<[typeof BAD_APP_MARKER, F, X]>;
type App<F, X> = [F] extends [Fun<infer K, infer C>] ? TypeFuncs<C, X>[K] : BadApp<F, X>;

const BAD_MAP_TUPLE = Symbol();
type MapTuple<F, T> =
    [T] extends never[] ? never[] :
    [T] extends [[infer T1]] ? [App<F, T1>] :
    [T] extends [[infer T1, infer T2]] ? [App<F, T1>, App<F, T2>] :
    [T] extends [[infer T1, infer T2, infer T3]] ? [App<F, T1>, App<F, T2>, App<F, T3>] :
    [T] extends [[infer T1, infer T2, infer T3, infer T4]] ? [App<F, T1>, App<F, T2>, App<F, T3>, App<F, T4>] :
    [T] extends [[infer T1, infer T2, infer T3, infer T4, infer T5]] ? [App<F, T1>, App<F, T2>, App<F, T3>, App<F, T4>, App<F, T5>] :
    [T] extends [[infer T1, infer T2, infer T3, infer T4, infer T5, infer T6]] ? [App<F, T1>, App<F, T2>, App<F, T3>, App<F, T4>, App<F, T5>, App<F, T6>] :
    [T] extends [[infer T1, infer T2, infer T3, infer T4, infer T5, infer T6, infer T7]] ? [App<F, T1>, App<F, T2>, App<F, T3>, App<F, T4>, App<F, T5>, App<F, T6>, App<F, T7>] :
    [T] extends [[infer T1, infer T2, infer T3, infer T4, infer T5, infer T6, infer T7, infer T8]] ? [App<F, T1>, App<F, T2>, App<F, T3>, App<F, T4>, App<F, T5>, App<F, T6>, App<F, T8>] :
    Invariant<[typeof BAD_MAP_TUPLE, F, T]>;

//type PromiseTuple<T extends any[]> = [Promise<E> for E in T];
const F_Promise = Symbol();
interface TypeFuncs<C, X> { 
    [F_Promise]: Promise<X>;
}
type F_Promise = Fun<typeof F_Promise, never>;
type PromiseTuple<T> = MapTuple<F_Promise, T>;

type T1 = PromiseTuple<[number, string, boolean]>;

[DanielRosenwasser]

Just to give an update, we've recently been discussing this within the team. We know this is one of the next problems we want to tackle.

We've wondered whether or not it makes sense for mapped object types to just specially act on tuple types.

So that

type PartialTuple = Partial<[T1, T2, T3]>

becomes

type PartialTuple = [T1?, T2?, T3?]

Or more broadly, something like

type T = [T1, T2, T3];
type WrappedTuple = { [K in keyof T]: Wrap<T[K]> };

is equivalent to

type T = [T1, T2, T3];
type WrappedTuple = [Wrap<T1>, Wrap<T2>, Wrap<T3>];

This is technically a breaking change, but is likely desirable for most cases.

Now, this is just my opinion, but to be honest, I am much more partial to the syntax that you have proposed. I would much rather not introduce a new special case for tuples on mapped object types.

However, this means that you now need to introduce a new Tuple version of every type alias helper in lib.d.ts (e.g. PartialTuple, RequiredTuple, etc.).

[jcalz]

If a "tuple-like" object (sequential "numeric" keys starting from "0", a compatible length property, and a bunch of array methods acting on the union of the element types) were automatically promoted to a tuple, then you could use mapped types to do something like it today:

type StripTuple<T extends any[] & (number extends T['length'] ? never : unknown)> =
  Pick<T, Exclude<keyof T, keyof Array<any>>>

type WrapTuple<T extends any[] & (number extends T['length'] ? never : unknown)> =
  Array<keyof StripTuple<T> extends infer K ? K extends any ? Wrap<T[K]> : never : never> &
  { length: T['length'] } &
  { [K in keyof StripTuple<T>]: Wrap<T[K]>}

type Wrapped = WrapTuple<[string, number, boolean]>
// essentially the same as [Wrap<string>, Wrap<number>, Wrap<boolean>]

But this doesn't really work because it isn't allowed in spread/rest positions... it's not seen as an "array type".

---

If mapped types do end up being special-cased to behave differently with arrays/tuples, that would probably be fine (actually, I feel like this was one of the motivating use cases for conditional types, since arrays were always messing things up)... as long as there were some way to work around it in the rare instances where you need to map an array/tuple like an object.

[jscheiny]

Glad to hear that this is being discussed and thanks for the feedback!

In my mind the main benefit of special casing mapped object types (outside of what's obvious/been mentioned i.e. familiarity, no extra type aliases) is that the syntax for adding/dropping type modifiers is pretty reasonable. Compare:

type M1 = { [K in keyof T]-?: T[K] };

To some of these potential (but ugly) options:

type M2 = [E for E-? in T];
type M3 = [E-? for E in T];

That being said I don't think that this should make or break which syntax is used. What's more important in my mind is what special casing mapped object types will do to the definition of keyof. This operator has already changed a decent amount recently and now it would change again when in a certain position for a certain type? This feels confusing and unnecessary to me.

As stated above, if the special case for mapped objects were added, it would still probably still be useful to occasionally treat array as objects for the purposes of mapping. Then we'd need some other special case / syntax for treating tuples as objects for mapping. Which would beg the question, why not just have some different syntax for mapping tuples in the first place?

[mattmccutchen]

How about this?

type M1 = [ [K in keyof T]-?: T[K] ];

Binding a variable to the index rather than to the element type of the original tuple lets you do lots of additional things (which may or may not be useful in practice) like zip two tuples:

type Zip<T1, T2> = [ [K in keyof T1 & keyof T2]: [T1[K], T2[K]] ];

The trouble is that we want only the numeric keys of T. We could say that in a mapped tuple, whatever you specify as the constraint type, only the numeric keys are kept, but that might be too tricky. To be consistent with mapped objects, we should probably require the specified constraint type to include only numeric strings. We could define a new built-in type Index that is the infinite union "0" | "1" | ... and then write:

type M1 = [ [K in keyof T & Index]-?: T[K] ];

Or a new operator indexof T that is equivalent to keyof T & Index. Unfortunately keyof T & number gives number, which doesn't work for present purposes, because tuples have a numeric index signature.

[jcalz]

@mattmccutchen

I think you can get just the "numeric" keys by doing Exclude<keyof T, keyof Array<any>>, as in StripTuple<>. (I do often want something like your Index type though... I usually call it NumericKey.)

That being said, I think that we adopt the [ [K in keyof T]: ... ] syntax (wrapped in [] instead of {}), it will just be understood that K in keyof T will only end up iterating over the numeric keys of T, and that the array methods and other special properties will inherit from Array<L> where L is the union of the post-mapped element types.

[mattmccutchen]

I think you can get just the "numeric" keys by doing Exclude<keyof T, keyof Array<any>>

Only assuming you started with a tuple type without extra properties. We might want to make it possible to do more wild and crazy things so we don't end up getting more feature requests in another few months.

[DanielRosenwasser]

#26063 went in - please give it a shot and give us feedback.

[jscheiny]

Will do, thanks for such a quick turnaround!

[RyanCavanaugh]

@DanielRosenwasser @jscheiny should this issue be closed then?