Feature Request: Tuples with variable type arguments

[JeroMiya]

Motivation:
Some JavaScript APIs take arguments of type Array, where the array is constructed, for example, by taking a number of items of one type followed by one or more arguments of another type, or perhaps the other way around. A real world example of this is the array-based dependency injection functionality in AngularJS, where you pass in an array consisting of a variable number of strings, followed by a function.

Motivating real world example:

angular.module('app').controller(['$scope', function($scope: ng.IScope) { /*etc...*/ }]);

// how we might type this in 1.3:
interface IModule {
  controller(injectable: () => any);
  controller(injectable: [string, () => any]);
  controller(injectable: [string, string, () => any]);
  controller(injectable: [string, string, string, () => any]);
  controller(injectable: [string, string, string, string, () => any]);
  // and so on, until we have 'enough' overloads to cover common usage
}

Suggestion:
Enhancement to the Tuple type annotation capability to support variable numbers of type arguments to support the above scenario without a fixed set of overloads.

Example tuple typing:

// same as controller function in the 1.3 example above
controller(injectable: () => any): void;
controller(injectable: [...string, () => any]): void {
  // type of expression injectable[n] is string | () => any
  // MAYBE special case for known indices: injectable[0] is type string and/or injectable[injection.length - 1] is () => any
}

// generalized examples (I don't have real-world examples of these, but might as well be comprehensive)
function foo1(variableLast: [() => any, ...string]) {
  // type of expression variableLast[0] is () => any
  // type of expression variableLast[n] is () => any | string
}
function foo2(variableFirst: [...string, () => any]) {}

// these forms might be possible, but doubtful there are real-world examples
// of these in JS apis, and would be bad practice in general. I would be OK if these
// forms were not allowed:
function foo3(variableMiddle: [string, ...number, () => any]) {
  // type of expression variableMiddle[0] is string
  // type of expression variable[n] is string | number | () => any
}
function foo4(twoVariables: [...string, ...number]) {}
function foo5(fixedInMiddleOfVariables: [...string, number, ...string]) {}

Edited: moved the ... token to the left of the type reference to more closely match the variable function argument syntax.

Edited 12/3/2014: examples foo3, foo4, and foo5 would be possible, but not likely to be used and bad practice. Documented this and separated them out from the first two examples, which are the real motivating ones.

Additional note: syncing function arguments with the number of type arguments in a tuple type is beyond the scope of this suggestion.

[mihailik]

Looks sensible. The obvious caution is how is this feature overlaps with varargs, when the variable-size argument is the one typed in this var-tuple way.

[JeroMiya]

Good point. I think that works out syntactically - this new syntax is bounded within the tuple annotation:

function foo(...injectables: [...string, (...args: any) => any]) {}

The issue is likely to be the inability to implement the same flexibility with function varargs as you can with variable tuple type arguments, because the function varargs are referencable individually:

// this we can't do, but we could
function example1(...arg1: string, arg2: number, arg3: string) {
}
// translation to JS:
function example1() {
  var arg1 = [];
  var arg2 = arguments[arguments.length - 2];
  var arg3 = arguments[arguments.length - 1];
  for(var _i = 0; _i < arguments.length - 2; _i++) {
    arg1[_i] = arguments[_i];
  }
}

// this we can do now
function example2(arg1: string, ...arg2: string) {}

// this we cannot do.
function example3(...arg1: string, ...arg2: number) {
  // what does the expression arg2[n] translate to? arg2.length? no way to tell at runtime
}

There might be a workaround if you could somehow specify varargs as a tuple instead of splats, but this could get confusing. Or you could just live with tuples being more flexible than varargs. Or, you could extend varargs to enable example1 above, and not allow foo3, foo4, or foo5 above, so that they're consistent.

Edit: updated example1 to match what the compiler currently does for varargs, slightly modified to support varargs at the beginning and fixed args at the end.

[NN---]

I have use case where array is typed differently for different indexes.

I would like to have this sample.
First item is a number and the rest items are objects with property 'prop'

class A {
 a: [x: number, ...rest: { prop: number; }] = [1, {prop:2}, {prop:3}];
}

[RyanCavanaugh]

Leaning toward "too complex" here unless there are more compelling examples than Angular's wacky DI setup. Might be worth discussing if we had a proof-of-concept PR that didn't introduce too much complexity.

[jods4]

@RyanCavanaugh what about the unlimited number of arguments passed to Promise.all. This example comes from a discussion in #1664.
Promise.all<X,Y,Z>([Promise<X>|X, Promise<Y>|Y, Promise<Z>|Z]): [X,Y,Z]

[saschanaz]

@jods4 That may also be related with #1773. With arbitrary syntax:

interface PromiseConstructor {
    all<...T[]>(...values: (T | PromiseLike<T>)[]): Promise<...T[]>
}

[panuhorsmalahti]

This would be useful when e.g. defining a table row like this:

const rows: [string, number, ..rest: any][] = []

const ID = 123;
rows.push(["My data", ID, prop1, prop2, prop3, prop4]);

[jameskeane]

@saschanaz Promise.all takes an Iterable. How would you suggest modifying your sample, assuming you were intending to specify rest parameters?

The following is similar to parameter packing in C++

module Promise {
  function all<...T_values>(
      values: [ (<T|Thenable<T>> T_values...) ]  // unpack, cast, then repack to tuple ?
  ): Promise<T_values> // keep it packed, assuming the type is a tuple of whatever types
}

Maybe now you see @RyanCavanaugh's point, about how complicated this can get. What other transformations will need to be supported?

Say I want to implement Array.flatten with support for variadic tuples, so we need to accept a variadic number of variadically typed tuples, then return a single variadic tuple?

How deep is the rabbit hole?

[saschanaz]

@jameskeane You may want to continue discussion here: #5453