Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variadic tuple types #39094

Merged
merged 37 commits into from Jun 23, 2020
Merged

Variadic tuple types #39094

merged 37 commits into from Jun 23, 2020

Conversation

@ahejlsberg
Copy link
Member

@ahejlsberg ahejlsberg commented Jun 16, 2020

This PR implements variadic tuple types, i.e. the ability for tuple types to have spreads of generic types that can be replaced with actual elements through type instantiation. The PR effectively implements the features discussed in #5453.

Some examples of new capabilities provided in this PR:

// Variadic tuple elements

type Foo<T extends unknown[]> = [string, ...T, number];

type T1 = Foo<[boolean]>;  // [string, boolean, number]
type T2 = Foo<[number, number]>;  // [string, number, number, number]
type T3 = Foo<[]>;  // [string, number]

// Strongly typed tuple concatenation

function concat<T extends unknown[], U extends unknown[]>(t: [...T], u: [...U]): [...T, ...U] {
    return [...t, ...u];
}

const ns = [0, 1, 2, 3];  // number[]

const t1 = concat([1, 2], ['hello']);  // [number, number, string]
const t2 = concat([true], t1);  // [boolean, number, number, string]
const t3 = concat([true], ns);  // [boolean, ...number[]]

// Inferring parts of tuple types

declare function foo<T extends string[], U>(...args: [...T, () => void]): T;

foo(() => {});  // []
foo('hello', 'world', () => {});  // ["hello", "world"]
foo('hello', 42, () => {});  // Error, number not assignable to string

// Inferring to a composite tuple type

function curry<T extends unknown[], U extends unknown[], R>(f: (...args: [...T, ...U]) => R, ...a: T) {
    return (...b: U) => f(...a, ...b);
}

const fn1 = (a: number, b: string, c: boolean, d: string[]) => 0;

const c0 = curry(fn1);  // (a: number, b: string, c: boolean, d: string[]) => number
const c1 = curry(fn1, 1);  // (b: string, c: boolean, d: string[]) => number
const c2 = curry(fn1, 1, 'abc');  // (c: boolean, d: string[]) => number
const c3 = curry(fn1, 1, 'abc', true);  // (d: string[]) => number
const c4 = curry(fn1, 1, 'abc', true, ['x', 'y']);  // () => number

Structure and instantiation

The basic structure of a non-generic tuple type remains unchanged with this PR: Zero or more required elements, followed by zero or more optional elements, optionally followed by a rest element (for example [A, B?, ...C[]]). However, it is now possible to have variadic elements anywhere in a tuple type, except following the optional rest element (for example [A, ...T, B?, ...U, ...C[]]).

A variadic elemement is a spread element of the form ...T, where T is a generic type constrained to any array or tuple type (specifically, any type that is assignable to readonly any[]). Intuitively, a variadic element ...T is a placeholder that is replaced with one or more elements through generic type instantiation. Instantiation of a tuple type with a variadic element ...T depends on the type argument provided for T as follows:

  • When the type argument for T is a union type, the union is spread over the tuple type. For example, [A, ...T, B] instantiated with X | Y | Z as the type argument for T yields a union of instantiations of [A, ...T, B] with X, Y and Z as the type argument for T respectively.
  • When the type argument is a tuple type, T is replaced with the elements of that tuple type. For example, [A, ...T, B] instantiated with [X, Y] as the type argument for T yields [A, X, Y, B].
  • When the type argument is an array type, T is replaced with a rest element. For example, [A, ...T] instantiated with X[] as the type argument for T yields [A, ...X[]].
  • When the type argument is another generic type, T is simply replaced with that type.
  • When the type argument is any, T is replaced with ...any[].
  • When the type argument is never, the entire result is never.

Instantiation of a generic tuple type includes normalization to ensure the resulting tuple type follows the basic structure described above. Specifically:

  • Optionality is removed from any optional elements that precede a required element. For example, [A?, ...T, B?] instantiated with [X, Y?] as the type argument for T yields [A, X, Y?, B?].
  • Rest elements absorb any following elements. For example, [A, ...T, B] instantiated with X[] as the type argument for T yields [A, ...(X | B)[]].
  • Tuples with only a single rest element are reduced to array types. For example, [...X[]] is reduced to simply X[].

Type relationships

Generally, a tuple type S is related to a tuple type T by pairwise relating elements of S to the elements of T. Variadic elements are processed as follows:

  • A variadic element ...U in S is related to a variadic element ...V in T if U is related to V.
  • A variadic element ...U in S is related to a rest element ...X[] in T if U is related to X[].

Some examples:

function foo1<T extends unknown[], U extends T>(x: [string, ...unknown[]], y: [string, ...T], z: [string, ...U]) {
    x = y;  // Ok
    x = z;  // Ok
    y = x;  // Error
    y = z;  // Ok
    z = x;  // Error
    z = y;  // Error
}

Tuple types with single variadic elements have the following relations:

  • [...T] is related to T.
  • T is related to readonly [...T].
  • T is related to [...T] when T is constrained to a mutable array or tuple type.

Some examples:

function foo2<T extends readonly unknown[]>(t: T, m: [...T], r: readonly [...T]) {
    t = m;  // Ok
    t = r;  // Error
    m = t;  // Error
    m = r;  // Error
    r = t;  // Ok
    r = m;  // Ok
}

Type inference

Inference between tuple types with the same structure (i.e. same number of elements and fixed, variadic, or rest kind matched to the same kind in each position), simply infers pairwise between the element types. For example, inference from [string, ...Partial<S>, number?] to [string, ...T, number?] infers Partial<S> for T.

Inference between tuple types S and T with different structure divides each tuple into a starting fixed part, a middle part, and an ending fixed part. Any one of these parts may be empty.

  • The starting fixed parts of S and T consist of those elements in S and T that are fixed (i.e. neither variadic nor rest elements) in both types matching from the start of each type.

  • If T contains at least one variadic element and S has no ending rest element, the ending fixed parts of S and T consist of those elements in S and T that are fixed in both types matching from the end of each type.

  • If T contains at least one variadic element and S has an ending rest element, the ending fixed part of T consists of those elements in T that are fixed matching from the end of the type, and the ending fixed part of S is empty.

  • If T contains no variadic elements, the ending fixed parts of S and T are empty.

  • The middle parts of S and T are those elements in S and T that remain between the starting and ending fixed parts of the types respectively.

Inference then proceeds as follows:

  • Pairwise infer between the elements in the starting parts.

  • If the middle part of S is a single rest element, infer from that rest element to every element in the middle part of T.

  • If the middle part of T is a single variadic or rest element, infer from a tuple consisting of the middle part of S to that variadic or rest element.

  • If the middle part of T is exactly two variadic elements ...A and ...B, and an implied arity exists for A, infer from a tuple consisting of the initial middle part of S to A and from a tuple consisting of the remaining middle part of S to B, where the length of the initial middle part corresponds to the implied arity for A.

  • Pairwise infer between the elements in the ending parts, or infer from the rest element in S to the elements of the ending part of T.

In the context of inference for a call of a generic function with a rest parameter R, the implied arity for R is the number of rest arguments supplied for R. In all other contexts, a type parameter has no implied arity. For an example of inference involving an implied arity, see the curry function in the introduction.

Some examples:

type First<T extends readonly unknown[]> = T[0];
type DropFirst<T extends readonly unknown[]> = T extends readonly [any?, ...infer U] ? U : [...T];
type Last<T extends readonly unknown[]> =
    T extends readonly [...infer _, infer U] ? U :
    T extends readonly [...infer _, (infer U)?] ? U | undefined :
    undefined;
type DropLast<T extends readonly unknown[]> = T extends readonly [...infer U, any?] ? U : [...T];

type T1 = First<[number, boolean, string]>;  // [number]
type T2 = DropFirst<[number, boolean, string]>;  // [boolean, string]
type T3 = Last<[number, boolean, string]>;  // [string]
type T4 = DropLast<[number, boolean, string]>;  // [number, boolean]

Spreads in array literals

When an array literal has a tuple type, a spread of a value of a generic array-like type produces a variadic element. For example:

function foo3<T extends unknown[], U extends unknown[]>(t: [...T], u: [...U]) {
    return [1, ...t, 2, ...u, 3] as const;  // readonly [1, ...T, 2, ...U, 3]
}

const t = foo3(['hello'], [10, true]);  // readonly [1, string, 2, number, boolean, 3]

When the contextual type of an array literal is a tuple type, a tuple type is inferred for the array literal. The type [...T], where T is an array-like type parameter, can conveniently be used to indicate a preference for inference of tuple types:

declare function ft1<T extends unknown[]>(t: T): T;
declare function ft2<T extends unknown[]>(t: T): readonly [...T];
declare function ft3<T extends unknown[]>(t: [...T]): T;
declare function ft4<T extends unknown[]>(t: [...T]): readonly [...T];

ft1(['hello', 42]);  // (string | number)[]
ft2(['hello', 42]);  // readonly (string | number)[]
ft3(['hello', 42]);  // [string, number]
ft4(['hello', 42]);  // readonly [string, number]

Indexing and destructuring

Indexing and destructuring of generic tuple types appropriately recognizes fixed elements at the start of the tuple type. Beyond the fixed elements, the type is simply a union of the remaining element types.

function f1<T extends unknown[]>(t: [string, ...T], n: number) {
    const a = t[0];  // string
    const b = t[1];  // [string, ...T][1]
    const c = t[2];  // [string, ...T][2]
    const d = t[n];  // [string, ...T][number]
}

function f2<T extends unknown[]>(t: [string, ...T, number], n: number) {
    const a = t[0];  // string
    const b = t[1];  // [string, ...T, number][1]
    const c = t[2];  // [string, ...T, number][2]
    const d = t[n];  // [string, ...T, number][number]
}

function f3<T extends unknown[]>(t: [string, ...T]) {
    let [...ax] = t;  // [string, ...T]
    let [b1, ...bx] = t;  // string, [...T]
    let [c1, c2, ...cx] = t;  // string, [string, ...T][1], T[number][]
}

function f4<T extends unknown[]>(t: [string, ...T, number]) {
    let [...ax] = t;  // [string, ...T, number]
    let [b1, ...bx] = t;  // string, [...T, number]
    let [c1, c2, ...cx] = t;  // string, [string, ...T, number][1], (number | T[number])[]
}

Rest parameters and spread arguments

Spread expressions with fixed length tuples are now appropriately flattened in argument lists. For example:

declare function fs1(a: number, b: string, c: boolean, ...d: number[]): void;

function fs2(t1: [number, string], t2: [boolean], a1: number[]) {
    fs1(1, 'abc', true, 42, 43, 44);
    fs1(...t1, true, 42, 43, 44);
    fs1(...t1, ...t2, 42, 43, 44);
    fs1(...t1, ...t2, ...a1);
    fs1(...t1);  // Error: Expected at least 3 arguments, but got 2
    fs1(...t1, 45);  // Error: Type '45' is not assignable to type 'boolean'
}

A rest parameter of a generic tuple type can be used to infer types from the middle part of argument lists. For example:

declare function fr1<T extends unknown[]>(x: number, ...args: [...T, number]): T;

function fr2<U extends unknown[]>(u: U) {
    fr1(1, 2);  // []
    fr1(1, 'hello', true, 2);  // [string, boolean]
    fr1(1, ...u, 'hi', 2);  // [...U, string]
    fr1(1);  // Error: Expected 2 arguments, but got 1
}

Application of mapped types

When a mapped type is applied to a generic tuple type, non-variadic elements are eagerly mapped but variadic elements continue to be generic. Effectively, M<[A, B?, ...T, ...C[]] is resolved as [...M<[A]>, ...M<[B?]>, ...M<T>, ...M<C[]>]. For example:

type TP1<T extends unknown[]> = Partial<[string, ...T, number]>;  // [string?, ...Partial<T>, number?]

Fixes #5453.
Fixes #26113.

ahejlsberg added 26 commits Jun 1, 2020
# Conflicts:
#	src/compiler/checker.ts
#	tests/baselines/reference/callWithSpread3.errors.txt
#	tests/baselines/reference/genericRestParameters1.errors.txt
#	tests/baselines/reference/ramdaToolsNoInfinite.types
@w0rp
Copy link

@w0rp w0rp commented Jun 26, 2020

This is out of the scope for this pull request, but I think it's the next most obvious thing to ask about for something to come next. Is there an open issue for supporting some way to compute the intersection of all types that are elements of a variadic type tuple, like T[0] & T[1] & ...? One use would be to declare Object.assign for any number of arguments.

What's interesting is that while I couldn't find a way to compute the intersection, computing the union of all of the elements was easy. I was able to make this pointless and fun function to return a random element.

const pickOne = <T extends unknown[]>(...args: [...T]): T[number] => {
    return args[Math.floor(Math.random() * args.length)]
}

console.log(pickOne({y: 3}, 4, ['foo'])
@DanielRosenwasser
Copy link
Member

@DanielRosenwasser DanielRosenwasser commented Jun 26, 2020

@w0rp I think you can use T[number], then pass that through something to convert a union type to an intersection type.

@TylorS
Copy link

@TylorS TylorS commented Jun 26, 2020

@w0rp There's some small differences between that union to intersection than being able to use & directly that are probably worth noting, but may be fine in some cases. Essentially, UnionToIntersection<A | B> does not always equal A & B - https://www.typescriptlang.org/play/#code/KYDwDg9gTgLgBDAnmYcCqAmAkgHjQPjgF4BYAKDjgAo05QZgA7AEwGc4BDRxOAfmoDWALnQBKYoQBuEAJbM4IxsEnAo4+kzbUqwuDMYAzVXCziiU2c3H8sCuEpVRy5JCjgAVAIzF02HAFdGAUYIAHdGOAAfOABvOAMICEV-AFsAI2MAX3wXZFR3DB9A4LCIgDJY+MTk9KygA

I've come up with an alternative using recursive conditional types which gives you more control over the transformation, by being able to customize then ToConsList type to work with any specific types you may be using. I've been using this to aggregate dependencies needed to perform a set of effects. I hope it helps 😄

@w0rp
Copy link

@w0rp w0rp commented Jul 1, 2020

@TylorS Thank you. That is pure genius. That's a pretty perfect solution.

@ahejlsberg
Copy link
Member Author

@ahejlsberg ahejlsberg commented Jul 20, 2020

@uhyo Regarding the "absorb" behavior in your example here, this is how you can constrain the type parameter to only permit inference of tuple types:

declare function pipe<T extends [] | [unknown, ...unknown[]]>(...args: [...T, (...values: [...T]) => void]): void;
@millsp
Copy link
Contributor

@millsp millsp commented Jul 20, 2020

This was passing on my tests not long ago, but seems to have broken:

export type Pop<L extends List> =
    L extends readonly [...infer LBody, any?]
    ? LBody
    : L

type t0 = Pop<[1, 2, 3?]> // now yields `unknown[]`, used to yield `[1, 2]`

Not sure if this is intended, so I am reporting anyway.

4.0.0-dev.20200720

@TylorS
Copy link

@TylorS TylorS commented Jul 20, 2020

Might be the wrong place for it, but I'd LOVE LOVE LOVE the above feature to work. It'd allow for generically modelling higher-kinded types in TypeScript without a giant plethora of overloads and fixes other DX-related issues with the current versions in libraries like fp-ts

@uhyo
Copy link
Contributor

@uhyo uhyo commented Jul 20, 2020

@ahejlsberg Thank you for your response!
However, that would still permit types like [number, ...number[]] which leads to a runtime error.
To completely prevent the absorb behavior in that example, we need a way to forbid arrays and also unconstrained-length tuple types, which I believe is impossible for now.

@ahejlsberg
Copy link
Member Author

@ahejlsberg ahejlsberg commented Jul 21, 2020

@millsp Yes, that's an effect of #39281. You can write it like this to get the prior result:

export type Pop<L extends List> =
    L extends (readonly [...infer LBody, any] | readonly [...infer LBody, any?])
    ? LBody
    : L;

You basically have to explicitly acknowledge that you want inferences from both optional and non-optional elements in the last position. It's subtle (as are many inference corner cases), but we'd otherwise have to introduce lower priority speculative inferences, as discussed in #39281, and I'd prefer to avoid that.

@ahejlsberg
Copy link
Member Author

@ahejlsberg ahejlsberg commented Jul 21, 2020

However, that would still permit types like [number, ...number[]] which leads to a runtime error.

@uhyo True, the only way to truly avoid this behavior would be for us to introduce "rest elements in the middle" support, but that's a non-trivial task and beyond the scope of 4.0.

@jdmichaud
Copy link

@jdmichaud jdmichaud commented Aug 13, 2020

Will the type of Promise.all be improved thanks to this?

@w0rp
Copy link

@w0rp w0rp commented Aug 13, 2020

Will the type of Promise.all be improved thanks to this?

That's a very good example of something that can easily be improved by using this. Maybe someone should raise an issue or create a pull request for it.

@IllusionMH
Copy link
Contributor

@IllusionMH IllusionMH commented Aug 13, 2020

It's already discussed in #39788

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

You can’t perform that action at this time.