Merging signatures using a union as rest parameters results in never.

[jespertheend]

Bug Report

🔎 Search Terms

merged parameters rest union never

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about union

⏯ Playground Link

Playground link with relevant code

💻 Code

type RestParams = [y: string] | [y: number];

type Signature = (x: string, ...rest: RestParams) => void;

type MergedParams = Parameters<Signature>; // never

🙁 Actual behavior

MergedParams is of type never.

🙂 Expected behavior

MergedParams is of type [x: string, y: string] | [x: string, y: number]

I realise this can sort of be done by using [y: string | number] as type for RestParams. However, I'm using unions in parameters like this in order to overload the signatures of functions in jsdoc as shown here: #25590 (comment)
If I use a union like that it will show up as union in VSCode, instead of using the multiple signatures UI.
Here's an example of this: Playground link.

[RyanCavanaugh]

@ahejlsberg what's the intended behavior here?

[ahejlsberg]

The core issue here is that we don't always consider equivalent signatures to be assignable. For example:

declare let f1: (...rest: [string, string] | [string, number]) => void;
declare let f2: (x: string, ...rest: [string] | [number]) => void;

f1 = f2;  // Error
f2 = f1;  // Error

Ideally the assignments above would be permitted as the signatures are functionally equivalent.

[ahejlsberg]

I should add that a workaround for the reported issue is to write the signature such that all parameters are specified in the rest tuple:

type RestParams = [x: string, y: string] | [x: string y: number];

type Signature = (...rest: RestParams) => void;

type MergedParams = Parameters<Signature>; // [x: string, y: string] | [x: string y: number]

But ideally that wouldn't be necessary.