Parameters<...> should always be spreadable

Bug Report

🕗 Version & Regression Information

Version: 4.5.4

⏯ Playground Link

Playground link

💻 Code

const doSomething = (arg:any) => !!arg

type ActionCreators = typeof doSomething

const dispatch = (action: ReturnType<ActionCreators>) => {
    console.log(action)
}

const withDispatch =<Action extends ActionCreators>(action:Action)=> (...args: Parameters<Action>)=> dispatch(action(...args)) // A spread argument must either have a tuple type or be passed to a rest parameter. (2556)
const withDispatchApply =<Action extends ActionCreators>(action:Action)=> (...args: Parameters<Action>)=> dispatch(action.apply(null, args)) // no error
const withDispatchCall =<Action extends ActionCreators>(action:Action)=> (...args: Parameters<Action>)=> dispatch(action.call(null, ...args)) // no error

🙁 Actual behaviour

When creating a higher order function that is going to operate on a certain set of functions TSC tells us A spread argument must either have a tuple type or be passed to a rest parameter.(2556) when we try to spread the arguments to it.

🙂 Expected behaviour

As with action.apply(null, args) and action.call(null, ...args) I expect that the inferred type of Parameters to always be spreadable.

[fatcerberus]

Somewhat surprisingly, (...args: string[]) => void extends (i.e. is assignable to) (arg: any) => any but taking its Parameters gives you string[], while the latter gives you [any]. So the spread gets disallowed because it doesn’t know whether the (deferred) Parameters will actually be compatible with the call (in practice it will because you’re calling a T with a Parameters<T> but that requires higher-level analysis than the compiler is currently capable of). AnyFn bypasses this because it’s explicitly declared with a rest parameter–meaning you can always call it with a spread per the second part of the quoted error message.

For what it’s worth, I’ve always felt there should be better error messages for generic cases like this. Rather than an absolute refusal (“is not assignable to”, etc.), the compiler should be clearer that it’s only preventing the operation because it can’t verify whether it’s safe.

[RyanCavanaugh]

The type Parameters<Action> is deferred so there’s not a way for TS to tell that this is always going to end up producing a type that happens to make a correct call. A type assertion is appropriate here

  /*[...]*/ action(...args as [any]);