Repeat parameter groups (including non-last rest parameter)

[niieani]

There are many JS libraries out there that take arguments in the form:

example(x1, y1, x2, y2, x3, y3, (...));

When writing a d.ts declaration file for them, there we can encounter many issues:

If all of the parameters are of the same type, say number it is trivial to describe using rest:

example(x1: number, y1: number, ...moreXandYs: Array<number>): any;

This already feels a bit hacky, since someone could provide an odd number of parameters (missing the last Y) and the type-checking would not spot the error.

On the other hand if the repeated parameters are of different type, or happen not to be at the end of the definition, there is currently no way to describe such methods, i.e.:

example(param1, x1, y1, x2, y2, x3, y3, (...), options);

For these types of methods to behave properly, the type definitions need to be even hackier (assuming X needs to be an interface of type XInterface and Y needs to be an interface of type YInterface and options is an object):

example(param1: string, ...Xs_And_Ys_And_Then_Options: Array<XInterface | YInterface | { validate: boolean }>): any

This works, but is really ugly and doesn't provide necessary type safety, since I could pass XInterface to a YInterface parameter, or even the options interface to an XInterface parameter.

There should be a way to define "argument repeat groups" that could behave the same way as ...rest parameters, but for multiple parameters at once, and could be placed anywhere in the method definition (not only at the end).

For real life use of such object parameter patterns, take a look at RethinkDB's JavaScript API.
Methods such as map() have their syntax specified as:

sequence1.map([sequence2, ...], a_function) → stream
array1.map([array2, ...], a_function) → array
r.map(sequence1[, sequence2, ...], a_function) → stream
r.map(array1[, array2, ...], a_function) → array

Parameters in the brackets are optional, while the ... means there can be more of those.

A "non-last rest" parameter for type declarations would solve 90% of these problems, so it could be a good start. Repeated groups of arguments are much rarer, but happen too, if you'd like to solve this issue in a more general way.

[RyanCavanaugh]

This doesn't seem common enough (I've literally never seen one?) that the existing solutions aren't "close enough" to warrant a complex solution like this.

As for non-terminal rest parameters, the ES6 committee didn't feel like that was something that should exist, and we're basically in agreement there.

[niieani]

@RyanCavanaugh regarding non-terminal rest parameters, I don't think it's necessary to implement that with desugaring into TypeScript (as you say, ES6 didn't see that as necessary).
I think that it makes sense for the declarations (type-checking) though, since it is a pattern I've seen in some JavaScript libraries, rethinkdb being a strong example of such usage.