When there is a var_args param, treat `arguments` like an Array of that type

[MatrixFrog]

While working on #152 I found a few places we're lacking type information because we don't know the type of the arguments object. For example at https://github.com/google/closure-library/blob/d0bd16969214db45c6719604e59bd46da8fce616/closure/goog/math/box.js#L76-77

it is obvious that coord is a goog.math.Coordinate from the type of the var_args parameter. But the compiler treats it as "unknown" because it doesn't know that arguments is an Array* of goog.math.Coordinate, so it doesn't know that arguments[i] is a goog.math.Coordinate.

• I know, it's not really an Array, but it's sufficiently Array-ish that we should know the type of its elements.

[blickly]

Probably we could only do this in cases where the only param is a var_args, right?
Or do you think that inferring the wrong type for
function f(x, y, var_args) { return arguments[0]; }
is acceptable?

[MatrixFrog]

We could have another pass that warns on arguments[0] and arguments[1]. But then if you have arguments[i] we wouldn't know what to do. So yeah, for now, let's focus on just the case where var_args is the only parameter.

[concavelenz]

This is another place that a tuple type would be useful.

[concavelenz]

I should also note that one of the consistent gatchas in javascript is that "arguments" doesn't have array methods, so treating as one is a bit of a problem is you can pass it or assign it as an Array.

[pauldraper]

Yeah, arguments can't be an Array.<T>. It would have to be an Arguments.<T>.

[concavelenz]

I think that this would be best to special case in this in the type system and just ignore it as the use of "arguments" should drop as people move to ES6's spread and rest features.

[usmonster]

Related: #153? The original issue concludes that an "array-like" type (with length, numbered keys/indices, and optional type information) would be welcome.. Is this still the case?