Parameters<Type> appears to produce incorrect type for function intersection types

[gwhitney]

Bug Report

🔎 Search Terms

Parameters intersection

🕗 Version & Regression Information

Version 3.7.5 - 4.8.2

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

Note the Playground stopped giving a coherent error message at 3.6.3 so I stopped testing prior versions there.

⏯ Playground Link

Playground link with relevant code

💻 Code

type InterFunc = ((x: number) => boolean) & ((y: string) => bigint)
type InterParam = Parameters<InterFunc>

const myParam: InterParam = [2.2]

🙁 Actual behavior

Compiler reports: Type 'number' is not assignable to type 'string' on the last line of the code.

As the type InterFunc specifies that with a single parameter of type number an InterFunc will return a boolean, it seems that an entity of type [number] should be assignable to a Parameters<InterFunc>, i.e., type InterParam.

🙂 Expected behavior

Code compiles without error. Given the semantics of function intersection types, it seems that InterParam should be the type [number | string], i.e. an InterFunc takes a single argument, which can be either a number or a string.

Aside: Although, I do have to admit, the exact semantics of function types are a trifle unclear. Function types seem to be minimal requirements, rather than exclusive specifications; given that InterFunc isn't never, that seems to mean that a function type like (x:number) => boolean means only "if given a number, I will return a boolean," with no claims or guarantees about will or won't happen if some other argument(s) are supplied (or no argument at all). From that point of view, Parameters<> is hard to understand in the first place, because it would seem that in fact an entity of type (x:number) => string could accept or not accept any arguments at all, other than it must accept a single number (just we have no information about the return type if we supplied a non-number argument). Strictly from that perspective, then, Parameters<T> should always return any[] as long as T is a function type at all. There doesn't seem to actually be any type which constrains what arguments a function can actually accept, since it seems to always be legal to intersect with another function type taking a different argument tuple without producing an empty type.

Hence, this bug is reported in the same spirit as Parameters<T> seems to be currently implemented: it is useful to be able to get at the formal parameters of a function type. It just does not seem that currently Parameters<T> does this correctly for function types that happen to be intersections.

[fatcerberus]

Intersections of function types are roughly semantically equivalent to overloads (which is why it’s legal to intersect them with any other function type), so this is similar to #50708 and ultimately probably a duplicate of #26591

[gwhitney]

Ah, well, this is exactly the function intersection version of #26591; sorry I didn't find that, as I was thinking only in terms of type intersections, not overloads. So if you are telling me that function intersection types are essentially the same as overloads, then I assume this will also be a "DesignLimitation" and there is no hope of it being fixed? Should I just close this issue myself then? I don't think I can put the DesignLimitation label on it, though.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.