Generic inference inside of `pipe` is incorrect when strict mode is disabled

[OliverJAsh]

TypeScript Version: 2.9.2

Search Terms:

Code

With strict mode disabled:

declare function pipe<V0, T1, T2, T3>(
 fn0: (x: V0) => T1,
 fn1: (x: T1) => T2,
 fn2: (x: T2) => T3,
): (x: V0) => T3;

type Option<T> = { t: T }
declare function optionOf<T>(value: T | null | undefined): Option<T>

declare function get(name: "set-cookie"): string[] | undefined;
declare function get(name: string): string | undefined;

// $ExpectType (x: {}) => Option<string>
// but got (x: {}) => Option<{}>
// Note: with strict mode enabled, we get the expected type.
const fn = pipe(
 ({}: {}) => 'foo',
 string => get(string),
 // Workaround: pass the function directly, instead of wrapping:
 // get,
 optionOf,
);

Related Issues:
This is similar to—but not exactly the same as—other issues I've filed when trying to use pipe:

• Incorrect overload is used for composed function inside pipe #25637
• Unexpected error/bad inference for generic composed function inside pipe #25791

[dardino]

from #25637 :

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 sorry

[OliverJAsh]

Mohamed Hegazy (@mhegazy) How come this is marked as a suggestion? Isn't this a bug?

[ahejlsberg]

Oliver Joseph Ash (@OliverJAsh) It's an effect (or limitation) of our type inference algorithm.

In the call to pipe we first make inferences from the first and third arguments because they are not "contextually sensitive" (i.e. they're not function expressions with parameters that have contextual types), and then finally from the contextually sensitive second argument. However, as we are inferring from the third argument, we end up fixing (i.e. freezing) inferences for T2 so that we can instantiate the generic optionOf in the context of (x: T2) => T3. That causes T2 to become {} (because we have no candidates for it). We then finally end up with an error because string | undefined isn't assignable to {} in --strictNullChecks mode.

We might explore doing better in situations where instantiation of a generic function argument in the context of a function type parameter causes fixing of type parameters and attempt to delay inference from such arguments further. That would be what the "Suggestion" label refers to.