Incorrect overload is used for composed function inside `pipe`

[OliverJAsh]

TypeScript Version: 2.9.2

Search Terms: generic function pipe contextual type wrong overload

Code

These examples are stripped down versions of Node's parse function in the querystring module and Lodash's values and fromPairs functions.

These are issues we ran into when trying to use these functions with a pipe function.

declare function pipe<A, B, C>(ab: (a: A) => B, bc: (b: B) => C): (a: A) => C;

{
 type ParsedUrlQuery = { [index: string]: string };
 declare function parsedUrlQueryString(str: string): ParsedUrlQuery;
 declare function parsedUrlQueryString<T extends {}>(str: string): T;

 declare const stringToString: (s: string) => string;

 // $ExpectType (a: string) => ParsedUrlQuery
 // but got (a: string) => {}
 // Note: if we comment out the last overload for `parsedUrlQueryString`, we get the expected
 // type.
 const fn = pipe(
 stringToString,
 parsedUrlQueryString,
 );
}

{
 declare function values<T>(object: { [index: string]: T } | null | undefined): T[];
 declare function values<T extends object>(object: T | null | undefined): Array<T[keyof T]>;
 declare function values(object: any): any[];

 declare const stringDictToStringDict: (
 sd: { [index: string]: string },
 ) => { [index: string]: string };

 // $ExpectType (a: { [index: string]: string; }) => string[]
 // but got (a: { [index: string]: string; }) => any[]
 // Note: if we comment out the last two overloads for `values`, we get the expected type.
 const fn = pipe(
 stringDictToStringDict,
 values,
 );
}

{
 declare function fromPairs<T>(pairs: [string, T][] | null | undefined): { [index: string]: T };
 declare function fromPairs(pairs: any[][] | null | undefined): { [index: string]: any };

 // $ExpectType (a: {}) => { [index: string]: number; }
 // but got (a: {}) => { [index: string]: any; }
 // Note: if we comment out the last overload for `fromPairs`, we get the expected type.
 const fn = pipe(
 ({ }: {}): [string, number][] => [['foo', 1]],
 fromPairs,
 );
}

[dardino]

Hi, I have a similar problem:

Playground

function a(value: any, replacer?: (string | number)[] | null, space?: string | number): string;
function a(value: any, replacer?: ((k: string, v: any) => any) | null, space?: string | number): string;
function a(value: any, replacer?: ((k: string, v: any) => any) | (string | number)[] | null, space?: string | number): string {
 return "";
}

var b = (value: any, replacer?: ((k: string, v: any) => any) | (string|number)[] | null, space?: string | number): string => {
 if (replacer instanceof Array || typeof replacer === "function")
 return a(value, replacer, space); // Why ERROR ??? function "a" supports both Array and function as 2nd parameter
}

[OliverJAsh]

Hey Mohamed Hegazy (@mhegazy), any idea if this is a bug or design limitation? Hopefully my examples demonstrate the frequency of this issue.

[mhegazy]

In Gabriele (@dardino)'s example the overloads do not include the implementation signature, so there is no overload that accepts (string | number)[] | ((k: string, v: any) => any), only ones that accept (string | number)[] | null or ((k: string, v: any) => any) | null`.

[mhegazy]

In the OP:
first set of overloads, the second overload of parsedUrlQueryString seems meaningless. removing it should cause the compiler to infer the right type.
Second and third sets, not sure what is going on, need to debug to figure it out

[OliverJAsh]

I simplified the parsedUrlQueryString overloads to demonstrate and isolate the issue—the full example does require that overload.

[dardino]

In Gabriele (@dardino)'s example the overloads do not include the implementation signature, so there is no overload that accepts (string | number)[] | ((k: string, v: any) => any), only ones that accept (string | number)[] | null or((k: string, v: any) => any) | null`.

Mohamed Hegazy (@mhegazy) Sure, but i think this is a bit limiting thing.
in fact I can write this to compile correctly: (that is very heavy)

var b = (value: any, replacer?: ((k: string, v: any) => any) | (string|number)[] | null, space?: string | number): string => {
 if (replacer instanceof Array)
 return a(value, replacer, space);
 if (typeof replacer === "function")
 return a(value, replacer, space);
}

I believe that is possible to make this assumption:
If all available overloads of a method can be called with current parameters types because they are compatible then the compiler can accept the call without errors:

class C1 { P1: string; }
class C2 { P2: string; }
class C3 { P3: string; }

function a(value: C1 | null): string;
function a(value: C2 | null): string;
function a(value: C1 | C2 | null): string {
 return "";
}

var c = (value?: C1 | C2 | C3 | null | undefined): string => {
 if (value instanceof C1 || value instanceof C2) 
 return a(value); // C1 | C2 --> not null or undefined, there is no reasons to give an error...
 // is a(C1) a valid call? YES
 // is a(C2) a valid call? YES
 // why error? 
 return value ? value.P3 : "";
}

var b = (value?: C1 | C2 | C3 | null | undefined): string => {
 if (value instanceof C1) return a(value); // C1
 if (value instanceof C2) return a(value); // C2
 return value ? value.P3 : "";
}

[OliverJAsh]

Gabriele (@dardino) This issue is concerning overloads when used with a pipe function, which doesn't appear to be the case with your issue. Perhaps you could open a new issue to avoid conflating the issue being tracked here?

[dardino]

ok

[Erikvv]

Looks like a duplicate of #10957

[weswigham]

Ref DefinitelyTyped/DefinitelyTyped#28592 which seems to have been motivated by this.

[OliverJAsh]

Revisiting this. This isn't specific to generic composed functions. I believe the issue can be narrowed down to:

{
 declare const pipe: {
 <A, B, C>(ab: (a: A) => B, bc: (b: B) => C): (a: A) => C;
 };

 declare const myFn: {
 (p: string): string;
 (p: any): number;
 };

 // Expected type: `(a: string) => string`
 // Actual type: `(a: string) => number`
 // Note: if we comment out the last overload for `myFn`, we get the expected
 // type.
 const fn = pipe(
 (s: string) => s,
 myFn,
 );
}

Any ideas Wesley Wigham (@weswigham)? Does this help?