A parameter not declared as a rest parameter is not one

[ghost]

Was looking at this with @sandersn yesterday.
Currently we allow this code:

/** @param {...*} a */
function f(a) {
    return a;
}
f(1, 2).push(3);

We think a is a rest parameter because the JSDoc declares it that way, but that doesn't change the fact that it isn't really a rest parameter.

[mihailik]

ES3/5 syntax does not allow for dot-dot-dot syntax.

Is there any way to declare rest parameter signature when using TS with ES3/5 JavaScript?

[ghost]

@mihailik I don't think there is, but we'll give you one for free anyway.

function f() {
    return arguments[1];
}

f(1, 2); // Works, because `arguments` appears in the function body.

[mihailik]

@Andy-MS that looks like best of both worlds, neat!

However I've just checked with typescript@next the example from the above:

node ./node_modules/typescript/lib/tsc.js multi.js --out multiout.js --allowjs

/** @param {...*} a */
function f(a) {
    return a;
}
f(1, 2).push(3);

Compiles with no error. Either I misunderstood this PR, or something is not right?

To be specific: --version gives Version 2.7.0-dev.20171021, running on Mac.

[ghost]

@mihailik You need --checkJs too or you'll never get errors in .js files.

[mihailik]

@Andy-MS

Thanks, I got the intended checking — no error on 2.5.2, error on typescript@next. But the magic arguments behaviour doesn't seem to work:

node ./node_modules/typescript/lib/tsc.js multi.js --out multiout.js --allowjs --checkjs

/** @param {...*} a */
function f(a) {
    return [arguments[arguments.length-1]];
}
f(1, 2).push(3);
  ~
multi.js(5,3): error TS2345: Argument of type '1' is not assignable to parameter of type 'any[]'.

To be specific: tsc --version returns:
Version 2.7.0-dev.20171024

[ghost]

That's because it's listening to the jsdoc which declares that a is an array. ...* is treated as the equivalent of any[]. a is the first parameter, not a rest parameter. So it expects the first parameter to be an array.

[mihailik]

@Andy-MS your original point seems to be correct (same according to Stackoverflow referring to JSDocs spec and Google Closure):

We think a is a rest parameter because the JSDoc declares it that way

Which is opposite to what you're saying right here above:

That's because it's listening to the jsdoc which declares that a is an array

My concern is to make sure idiomatic ES5-style code exposing API with variable parameters is handled the right way. Thanks a lot!

[ghost]

Well, in the first example I'm describing a bug! If a really is a rest parameter, then the jsdoc should be declared with ... and it makes sense to give it an array type. You might argue that we should give an error if the jsdoc uses ... but the actual variable doesn't.

[mihailik]

@Andy-MS looks like we have another bug introduced here. Here's a bit clearer example from above:

node ./node_modules/typescript/lib/tsc.js multi.js --out multiout.js --allowjs --checkjs

/** @param {...number} a */
function f(a) {
    console.log(arguments[0]);
}
f([1, 2]); // this should fail, but passes
f(1, 2); // this should pass, but fails
  ~
multi.js(6,3): error TS2345: Argument of type '1' is not assignable to parameter of type 'number[]'.

This is a valid idiomatic proper JavaScript: declare a function with variable number arguments. Compiler incorrectly assumes the argument is of type number[].

[ghost]

Well, like I said above, we could add a diagnostic for if you declare a rest parameter in JSDoc but the corresponding parameter (a) isn't a rest parameter.

[mihailik]

Then it's a regression, unfortunately. That is a valid way to implement rest parameter in ES5.