Repository navigation
Type inference for rest parameters differs from that for arrays #41048
Description
TypeScript Version: 4.1.0-dev.20201011
Search Terms: rest parameters, type inference
Expected behavior: All test cases are valid ones.
Actual behavior: cases t3 and t4 are correctly understood by the TS compiler, the other ones result in errors:
Argument of type 'number' is not assignable to parameter of type 'string'.
Argument of type '"b"' is not assignable to parameter of type '"a"'.
Related Issues: #37193
Code
declare function f1<T>(...list: ReadonlyArray<T>): T;
declare function f2<T>(...list: T[]): T;
declare function f3<T>(list: T[]): T;
const s:string = "str";
const ar = ["a", "b", "c", 0];
const t1 = f1(s, "a", "b", 0);
const t2 = f2("a", "b", "c", 0);
const t3 = f3(["a", "b", "c", 0]);
const t4 = f1(...ar);Output
"use strict";
const s = "str";
const ar = ["a", "b", "c", 0];
const t1 = f1(s, "a", "b", 0);
const t2 = f2("a", "b", "c", 0);
const t3 = f3(["a", "b", "c", 0]);
const t4 = f1(...ar);Compiler Options
{
"compilerOptions": {
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictPropertyInitialization": true,
"strictBindCallApply": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"alwaysStrict": true,
"esModuleInterop": true,
"declaration": true,
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"moduleResolution": 2,
"target": "ES2017",
"jsx": "React",
"module": "ESNext"
}
}Playground Link: Provided
Activity
RyanCavanaugh commentedon Oct 12, 2020
These are different syntaxes and thus mean different things; by having different syntax do different things you are then able to express different behavior depending on which you want to happen. Changing either one of these behaviors would be a fairly large breaking change and would need to be justified by something more than "it's different".
ezsh commentedon Oct 12, 2020
I don't think it works as intended: the
t1case is failing because TS deduces theTtype from the first argument only, while it has to use the whole arguments array. For thet2case the type ofTis inferred as "a", which is obviously useless and wrong.RyanCavanaugh commentedon Oct 12, 2020
This is the intended behavior. In
t2, inference failed to produce a suitable result, so the call was processed according to the first available candidate, which was"a".ezsh commentedon Oct 12, 2020
I can't agree with you. MDN states: "A function's last parameter can be prefixed with ... which will cause all remaining (user supplied) arguments to be placed within a "standard" JavaScript array."
But this is not the case with TS: for rest parameters it fails to deduce the same union type as it does for array. I'd expect it to infer
Tto bestring|numberfort1and"a" | "b" | "c" | numberfort2, right as it does that for theardeclaration.ezsh commentedon Oct 12, 2020
And in any case, all four examples are valid, if TS can't (or does not want to) infer the correct union type, it should have set
Ttoanyinstead of signalling errors.RyanCavanaugh commentedon Oct 12, 2020
"valid" and "correct" are outcomes decided by the type system, and the type system has intentionally been designed with flagging some of these as errors as not others.
ezsh commentedon Oct 12, 2020
The type system is wrong then: semantically rest parameters do not differ from arrays is JS, while TS assign them different behaviour. The
t4case is semantically identical to thet1, but TS handles them differently, which is incorrect.