Higher order function inference breaks with multiple overloads

[OliverJAsh]

TypeScript Version: 3.3.3333, 3.4.0-dev.20190313

Search Terms: higher order function generic param inference any reselect

Code

This is an issue I found whilst using the popular Reselect library, however I believe it is a bug with TypeScript rather than the type definitions. Here is a minimal repro.

type Selector<S, R> = (state: S) => R;
type ParametricSelector<S, P, R> = (state: S, props: P) => R;

// Comment out this overload and things work as expected
declare function createSelector<S, R1, R2>(
    selector1: Selector<S, R1>,
    selector2: Selector<S, R2>,
): void;
declare function createSelector<S, P, R1, R2>(
    selector1: ParametricSelector<S, P, R1>,
    selector2: ParametricSelector<S, P, R2>,
): void;

type Props = { foo: 1 };
createSelector(
    (
        // Expected `state` param type to be inferred as `{}` (fallback)
        // Actual type: `any`
        state,
        props: Props,
    ) => props.foo,

    (
        // Expected `state` param type to be inferred as `{}` (fallback)
        // Actual type: `any`
        state,

        // Expected `props` param type to be inferred as `Props`
        // Actual type: `any`
        props,
    ) => props.foo,
);

// Workaround: annotate first function's state param
type State = {};
createSelector(
    (state: State, props: Props) => props.foo,
    (state, props) => props.foo,
);

[RyanCavanaugh]

In general we can't do overload resolution at the same time as inference and will usually be working with either the first or the last overload, depending on the situation

[OliverJAsh]

Thanks for the explanation. How come any is used as the fallback instead of {} (which is the usual generic inference fallback)?

[PoldarnKJ]

Thanks for the explanation. How come any is used as the fallback instead of {} (which is the usual generic inference fallback)?

In your example code:

createSelector(
    (
        // Expected `state` param type to be inferred as `{}` (fallback)
        // Actual type: `any`
        state,
        props: Props,
    ) => props.foo,

The state param cannot be infer as other type except any(I test it in Typescript@3.5.1, the result is unknown), because your code doesn't provide any information about the state param.
And the following code:

Expected props param type to be inferred as Props

If you comment the overload type signature, it will work well, because the compiler can infer it's type from
the previous context:

    (
        // Expected `state` param type to be inferred as `{}` (fallback)
        // Actual type: `any`
        state,
        props: Props,
    ) => props.foo,

So, in your example code, the props and state can't be refer as you expect because two different reason.

[PoldarnKJ]

In general we can't do overload resolution at the same time as inference and will usually be working with either the first or the last overload, depending on the situation

It is true, however, is there any solution?
Or, this behavior is OK?
I try the following code:

const f = <I, R>(f: (x: I) => R): ((x: I) => R) => (x: I) => f(x);
interface Fn {
  (x: number): number;
  (x: string): string;
}

declare const fn: Fn;

// type of `r` is (x:string)=>string, the `union type` property is lost
const r = f(fn);

The result type is make me upset.

---

I found a solution for the above case:

const f = <I, R ,F extends (x: I) => R>(f: F): F => {
    return ((x: I) => f(x) )as unknown as F
};
interface Fn {
    (x: number): number;
    (x: string): string;
}

declare const fn: Fn;

// type of `r` is Fn, `union type` property is preserve
const r = f(fn);
// work 
const v = r('1')

But it work just for the above specify case, it not solve the problem:

When unpack union type of function to something like (x:T)=>R, the union type property is lost

[Avaq]

In general we can't do overload resolution at the same time as inference and will usually be working with either the first or the last overload, depending on the situation -- @RyanCavanaugh

We seem to have run into this issue, documented here: fluture-js/Fluture#403
But interestingly, "usually be working with either the first or the last overload" is not happening - instead we're getting a type that seems to be a combination of the first overload and the second overload. Is that still this same issue, and as such to be considered a TypeScript design limitation, or have we run into something else?