GeezerVison

thanks for your great working🤩

This looks incredible and I can't wait to make use of this.

Open-ended tuple types (in progress).

That sounds amazing - this would allow us to type the return value of string.split() as always having at least one element:

split(delimiter: string): [string, string*]

In a world where we have #13778, that would mean the types for destructured split would be correctly inferred:

// [string, string | undefined]
const [package, version] = '[email protected]'.split('@')

The * Kleene star looks a bit weird because it is not used for rest syntax in JS. Maybe spread syntax could be used? This would align with a future generic type spread operator: [string, ...number[]]
The inner array type is spread into the tuple.

Great!,
I think you made a typo in the comment of f1. shouldn't z be of type boolean?

const f1 = bind(f2, "hello");  // (z: boolean) => void

Great work! Now TypeScript is one step closer to #5453!

Rather than having [string, number*], could we support spread operator in types as well, so we could have something like [string, ...number[]]?

Zhongliang Wang (@Cryrivers)

Rather than having [string, number*], could we support spread operator in types as well, so we could have something like [string, ...number[]]?

Or just have multiple rest arguments: (a: string, ...rest: [string, number], ...restLast: string[])

But tuples can't be infinite by definition?

andretshurotshka (@goodmind) before this PR, tuples are fixed sized.

Van den Berghe Jo (@jovdb) Yes, that was a typo. Now fixed. Thanks for catching.

Anders Hejlsberg (@ahejlsberg) can this be used to type compose, pipe or curry?

Felix Becker (@felixfbecker) Zhongliang Wang (@Cryrivers) There are two ways we could go on the syntax for the last element in an open-ended tuple:

[string, number*]
[string, ...number[]]

The latter is longer but certainly makes it easier to see the connection to rest parameters. If we go with the latter, the last element will be required to have an array type. This PR will specifically not permit the equivalent of generic rest parameters in tuples--that would add considerable complexity. But certainly the ...X syntax would better accommodate that feature later on, should we choose to go there.

I think the last type being required to be an array is perfectly acceptable.

This is a wonderful step forward!

+1 to the [string, ...number[]] syntax, I feel despite its verbosity it would keep the syntax intuitive to JS users.

Potential extensions needed for the functions andretshurotshka (@goodmind) mentioned:

• generic support (the ...X mentioned by Anders Hejlsberg (@ahejlsberg))
• expanding tuple types in tuple type literals (tuple type spread #17884) (edit: same as Concat, defined by @fightingcat at TypeScripts Type System is Turing Complete #14833):

type Tpl = [string, number];
type MyTpl = [...Tpl, boolean];

(^ or using a generic Tpl, as above)

I believe that the better choice for the open-ended tuple syntax is [ ... string[] ].

Star has two benefits: arguably better syntax, and preventing generic rest parameters (edit: for now 😝). The latter is solved as Anders Hejlsberg (@ahejlsberg) notes by always requiring the last element to have an array type, which I think is a reasonable restriction.

Syntactically, I guess * looks very foreign to JS developers and that most would prefer a more familiar syntax (this thread is good evidence, thanks everyone!). * also opens up a whole can of worms around which "regexp-type operators" are supported (e.g. can we write [string, string*] as [string+]?). Lastly, if we get full support for variadic types, the ... syntax will have to be supported anyway, and thus we will end up with two syntaxes for the same thing (i.e. [number, string*] and [number, ... string[]] and presumably a lint rule to make one or the other preferred).

I think we should just adopt the javascripty syntax that will be intuitive to those with experience using rest/spread and is a pure subset of existing proposals for variadic types and others.

T["length"] example

type Take<N extends number, T extends any[], R extends any[]=[]> = {
  0: Reverse<R>,
  1: Take<N, Tail<T>, Cons<Head<T>, R>>
}[T extends [] ? 0 : R["length"] extends N ? 0 : 1];

export type Group<N extends number, T extends any[], R1 extends any[]=[], R2 extends any[]=[]> = {
  0: Reverse<R2>,
  1: Group<N, T, [], Cons<Reverse<R1>, R2>>,
  2: Group<N, Tail<T>, Cons<Head<T>, R1>, R2>
}[T extends [] ? R1 extends [] ? 0 : 1 : (R1["length"] extends N ? 1 : 2)];

export type Drop<N extends number, T extends any[], R extends any[]=[]> = {
  0: T,
  1: Drop<N, Tail<T>, Cons<Head<T>, R>>
}[T extends [] ? 0 : R["length"] extends N ? 0 : 1];

Hello - this fix apparently makes this possible: #24897 but I can't for the life of me figure out how and that thread has been closed now.

I am trying to implement a signal that is used in the following way:

const mySignal = Signal<string, number, SomeType>()
mySignal.emit('sdf', 123, someObj)

So basically emit uses rest arguments that are typed when the signal is created.

Could someone point me in the right direction regarding what the generics for this might look like?

Many thanks!