You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rest tuple parameter with intersection/union places error on wrong argument #28505
declarefunctionboop<Textendsany[]>(...args: T&[number,string]): void;boop(123,456);// error// ~~~ <-- error on first argument// Argument of type '[123, 456]' is not assignable to parameter // of type '[number, number] & [number, string]'.// Type '[123, 456]' is not assignable to type '[number, string]'.// Type '456' is not assignable to type 'string'.
Expected behavior:
I expect an error on the second argument (456), since that's the argument that causes the failure, as made evident by the error message. (Or possibly I expect an error on both arguments, if it's interpreted as a failure to match the rest parameter.)
Actual behavior:
The actual error is on the first argument (123). This is a minor problem, and it only seems to show up in the intersection-with-type-parameter situation above (concrete types like ...args: [number, string] & [number, string] work fine), but I figured I'd report it in case it has an easy fix.
declarefunctionboop<Textends[number,string]>(...args: T|[number,boolean]): void;boop(123,456);// error// ~~~ <-- error on first argument// Argument of type '[123, 456]' is not assignable to parameter // of type '[number, string] & [number, boolean]'.// Type '[123, 456]' is not assignable to type '[number, string]'.// Type '456' is not assignable to type 'string'.
changed the title [-]Inferred tuple type rest parameter with intersection seems to place error on wrong argument[/-][+]Tuple type rest parameter with intersection/union places error on wrong argument[/+]on Jan 16, 2021
changed the title [-]Tuple type rest parameter with intersection/union places error on wrong argument[/-][+]Rest tuple parameter with intersection/union places error on wrong argument[/+]on Jan 16, 2021
Activity
jack-williams commentedon Nov 13, 2018
Think the same happens with unions too:
jcalz commentedon Jan 16, 2021
I see generics aren't even needed to reproduce this:
Playground link
[-]Inferred tuple type rest parameter with intersection seems to place error on wrong argument[/-][+]Tuple type rest parameter with intersection/union places error on wrong argument[/+][-]Tuple type rest parameter with intersection/union places error on wrong argument[/-][+]Rest tuple parameter with intersection/union places error on wrong argument[/+]