Repository navigation
Inconsistent inferred overloads in conditional types for no-arg signatures with strictFunctionTypes #28867
Description
Activity
As i mentioned in duplicate issue - problem not only in no arg function. also with
(x: unknown) => any,(x: any) => any,(...args: unknown[]) => anyetc.type Overloads<F> = F extends { (...args: infer A1): infer R1 (...args: infer A2): infer R2; } ? {rule: 2, variants: [A1, R1] | [A2, R2]} : F extends { (...args: infer A1): infer R1; } ? {rule: 1, variants: [A1, R1]} : never; declare const ok1: Overloads<(x: number) => boolean>; // {rule: 1, variants: [[number], boolean]} declare const ok2: Overloads<{(): 1; (x: number): 2}>; // {rule: 2, variants: [[], 1] | [[number], 2]} declare const wrong1: Overloads<() => boolean>; // {rule: 2, variants: [[], boolean] | [unknown[], {}]} // expected {rule: 1, variants: [[], boolean]} declare const wrong2: Overloads<(...args: unknown[]) => boolean>; // {rule: 2, variants: [unknown[], boolean] | [unknown[], {}]} // expected {rule: 1, variants: [unknown[], boolean]} declare const wrong3: Overloads<(x: unknown) => boolean>; // {rule: 2, variants: [[unknown], boolean] | [unknown[], {}]} // expected {rule: 1, variants: [[unknown], boolean]} declare const wrong4: Overloads<(x: any) => boolean>; // {rule: 2, variants: [[any], boolean] | [unknown[], {}]} // expected {rule: 1, variants: [[any], boolean]}
Reacted by Artur Bier, Titian Cernicova-Dragomir, Joe Calzaretta, Jason Kwok, snailuj, Huan Li and SlurpTheoReacted by Huan LiRelevant SO question: How to use Parameters type on overloaded functions?
8 remaining items
When inferring between types with multiple signatures, we match the signatures pairwise from the bottom up. This is a fine strategy when the source and target have matching arities (number of signatures) and when the source arity is greater than the target arity. But when the source arity is less than the target arity we never make inferences to the excess signatures in the target. That is a suboptimal strategy because in the absence of inference candidates we infer the constraint (which in turn defaults to
unknown) and that may end up producing very restrictive signatures.We want to ensure that every signature in the target is matched with some signature in the source, so a better strategy is to infer between signatures pairwise from the bottom up and then infer from the first source signature to each of the excess target signatures. I will put up a PR to that effect.
Reacted by Joe Calzaretta and Ryan Cavanaugh
TypeScript Version: 3.3.0-dev.20181205
Search Terms:
conditional type, infer, overload, no-arg, zero arguments, strictFunctionTypes
Note that this issue is not about the behavior where the last overload is examined in conditional type inference of a single signature, where some might expect a union or an argument-based choice.
Code
Expected behavior:
I would expect that either both
JustOneSignatureandJustTheOtherSignaturewould benever, or bothJustOneSignatureandJustTheOtherSignaturewould evaluate to a two-tuple where the first signature is... something. I suppose(...a1: unknown[])=>{}? Or maybe it should be a copy of one of the other overloads? Or something in between?Actual behavior:
It looks a zero-argument function is being treated pathologically during conditional type inference; if a type is callable with zero arguments, it will be considered assignable to any number of overloads with what looks like failed inference for the types of the arguments (
unknown[]) and the return ({}). Otherwise, if a type is only callable with at least one argument, it will only be considered assignable to the matching number of overloads.This distinction only seems to happen with
--strictFunctionTypeson. If you turn it off,JustOneSignatureabove becomes[(...a1: unknown[]) => {}, (x: string) => number], which is at least consistent with the zero-argument situation.Playground Link:
🔗
Related Issues: