Allow rest elements to follow other rest elements in tuple types

[Mateusz Burzyński (Andarist)]

I think that this restriction is somewhat artificial and doesn't bring a lot of value. Those are allowed and work OK:

typeOk1=[...Array<number>, ...Array<string>]typeAlias=string[]typeOk2=[...number[], ...Alias]

[TypeScript Bot (typescript-bot)]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[David Blass (ssalbdivad)]

Thoughts on going the other direction and erroring in both cases?

[...number[], ...string[]] does imply more than just (number | string)[]. Barring a robust sequential representation and some advanced narrowing to make it usable, it feels safer just to error rather than implicitly weaken the constraints.

[Mateusz Burzyński (Andarist)]

I dont rly think that multiple variadic elements in a tuple are usable. Even trailing non-variadic elements are already quirky to handle at runtime

[David Blass (ssalbdivad)]

Mateusz Burzyński (@Andarist) Yeah you convinced me it wouldn't be worth implementing last time we discussed it.

That said, I think given that, do you think disallowing every form of [...Array<number>, ...Array<string>] could be the safer option to avoid implicitly weakening the defined type?

[Mateusz Burzyński (Andarist)]

It would be a breaking change. The behavior of combining different tuple types through a normalization algorithm sounds useful to me. It also supports more than just multiple rest elements, optional ones are also supported, and with your proposal, all of that would have to be an error. Example of what works today:

typeA=[number,string?];typeB=[...boolean[],boolean];typeC=[bigint, ...bigint[], ...B, ...A];// [bigint, ...(string | number | bigint | boolean | undefined)[]]

[David Blass (ssalbdivad)]

Mateusz Burzyński (@Andarist) I'm not suggesting A and B not continue to work as they do currently, just that C not be implicitly weakened to a union of its elements.

Whether TS supports it or not (and I understand why doing so doesn't seem worthwhile), [...number[], ...string[]] has a distinct meaning as a type that is stricter than (number | string)[]. I don't see a good reason to allow definitions like that that can't actually be enforced over requiring the weaker form directly.

[Mateusz Burzyński (Andarist)]

That still would be a breaking change for cases like this:

typeJoinArrays<T1extendsreadonlyunknown[],T2extendsreadonlyunknown[]>=[...T1, ...T2]typeResult1=JoinArrays<string[],number[]>// (string | number)[]

This behavior is rather useful and we can't disallow JoinArrays being a thing since very useful things would get disallowed:

typeJoinArrays<T1extendsreadonlyunknown[],T2extendsreadonlyunknown[]>=[...T1, ...T2]typeResult2=JoinArrays<[number,number],[boolean]>// [number, number, boolean]

We have variadic elements here (and not rest ones). Technically it's trivial~ to allow this while disallowing multiple rests. Syntactically they both look the same though. I find it a hard sell for only one of them to work. If the generic variant with variadic elements works and we can "join" array types using it then IMHO it only makes sense for the non-generic case to work in the same way.

[David Blass (ssalbdivad)]

Mateusz Burzyński (@Andarist) Good point, I hadn't considered this. That may actually help clarify some of the motivation for the seemingly arbitrary existing behavior.

Perhaps the intention was to disallow multiple rest elements when it would always just be reduced to a union. If that is the case, Array<T>, ReadonlyArray<T> etc. should also error when used like this, whereas aliases (ideally only those bound to generic parameters) would continue to be allowed, falling back to the union behavior when necessary.

While I think this approach could help avoid some unexpected results, neither approach feels great and I understand wanting to standardize the behavior. Given this, I think the ideal solution really would be to implement a restrictive version of [...number[], ...string[]] as a builtin type, but from an ROI perspective it's probably just not worthwhile.

[Mateusz Burzyński (Andarist)]

superseded by 70715ea (that belongs to #57031 )