Intersection of multiple type guard function types (or multiple overloads) has inconsistently inferred predicate types

[lazytype]

Bug Report

🔎 Search Terms

type guard assertion function intersection predicate

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about type guards

⏯ Playground Link

Playground link with relevant code

💻 Code

type GuardIntersection = ((x: unknown) => x is number | string) &
    ((x: unknown) => x is number | boolean);

type AssertionIntersection = ((x: unknown) => asserts x is number | string) &
    ((x: unknown) => asserts x is number | boolean);

type GuardType = GuardIntersection extends (x: any) => x is infer U ? U : never;
//   ^?
//      type GuardType = number | boolean

type AssertionType = AssertionIntersection extends (x: any) => asserts x is infer U ? U : never;
//   ^?
//      type AssertionType = number | boolean

function example(guard: GuardIntersection, assertion: AssertionIntersection, x: unknown): number {
    if (guard(x)) {
        return x;
        //     ^?
        //        (parameter) x: string | number
    }

    assertion(x);
    return x;
    //     ^?
    //        (parameter) x: string | number
}

🙁 Actual behavior

When using infer to extract the predicate type of the intersection of type guard function types, the predicate type of the last item in the intersection is inferred. (number | string)
When calling a type guard function of the intersection type, the argument of the type guard function is narrowed to the predicate type of the first item in the intersection. (number | boolean)

🙂 Expected behavior

In both cases, I'd expect the inferred/narrowed type to be the intersection of the predicate types. (number)
At the very least I'd expect the two types to be the same.

Aside: This is remarkably similar to the behavior of inferring the return type of function overload types (#26591). Coincidence?

[fatcerberus]

This is remarkably similar to the behavior of inferring the return type of function overload types (#26591). Coincidence?

Probably not. Overloads are represented internally as intersections of function types.

[DanielRosenwasser]

Overloads are represented internally as intersections of function types.

As an aside, this is not quite true - each object type has some number of call signatures and construct signatures. When constructing an intersection, those lists of signatures are combined.

[DanielRosenwasser]

I do think that this is the same as #26591 actually - and @fatcerberus please feel free to correct me if you believe I've missed something.

Some explanation:

1. When you call a function, TypeScript tries to figure out the right overload. This process is a "first-success-wins" one, where the first parameter list that's compatible with the arguments gets picked. That's why you get the result of the first signature: string | number.

   As you can see, that has undesirable consequences in the case of an intersection type with some identical parameter types, since signature lists are just ordered consecutively.
   

2. When you extract types out with a conditional type, we pick the last overload because the assumption is that it's the most general.

   As you can see, this has undesirable consequences when there are multiple signatures with the same parameter lists. That isn't common, but it comes up in intersection types - same as before.
   

Deciding to merge signatures would be a pretty big change. The closest thing I can imagine is something we do when trying to access a method from a union type so that you can do something like .map(...) on an Array<string> | Array<number> - but I believe we only do that when the method originates from the same source. @weswigham knows more.

Changing the behavior now would be breaking; however, I don't know who relies on the conditional type ordering behavior for overloads because conditional types are fundamentally...just weird when operating on overloads (as described in those links).

[DanielRosenwasser]

Retitling the issue - the following code (playground link) has the same behavior regardless of intersections - it all comes down to multiple overloads.

type GuardIntersection = {
    (x: unknown): x is number | string;
    (x: unknown): x is number | boolean;
};

type AssertionIntersection = {
    (x: unknown): asserts x is number | string;
    (x: unknown): asserts x is number | boolean;
};

type GuardType = GuardIntersection extends (x: any) => x is infer U ? U : never;
//   ^?
//      type GuardType = number | boolean

type AssertionType = AssertionIntersection extends (x: any) => asserts x is infer U ? U : never;
//   ^?
//      type AssertionType = number | boolean

function example(guard: GuardIntersection, assertion: AssertionIntersection, x: unknown): number {
    if (guard(x)) {
        return x;
        //     ^?
        //        (parameter) x: string | number
    }

    assertion(x);
    return x;
    //     ^?
    //        (parameter) x: string | number
}

[DanielRosenwasser]

I guess duplicate is the wrong label - #26591 is related, but this report is about the divergence between overload resolution and inference.

[fatcerberus]

@DanielRosenwasser I’m just going on @RyanCavanaugh saying many times in the past that the type of an overloaded function is equivalent to an intersection of the overload signatures.

[DanielRosenwasser]

Ah, gotcha - internally it's more of the opposite. When we need the "apparent members" of a type, the corresponding signatures naively get smushed into a single signature list.

[lazytype]

This isn't the original problem I was trying to solve, but just thought I'd share a use case where this can matter

function combineTypeGuards2<T, U>(p1: (obj: any) => obj is T, p2: (obj: any) => obj is U) {
    return (obj: any): obj is T & U => p1(obj) && p2(obj);
}

const combined2: (obj: any) => obj is number = combineTypeGuards2(
    (obj: unknown): obj is number | string => true,
    (obj: unknown): obj is number | boolean => true,
);

/**************************************************************************/

type GuardType<T> = T extends (x: any) => x is infer U ? U : never;

function combineTypeGuardsN<T extends Array<(obj: any) => obj is unknown>>(...args: T) {
    return (obj: any): obj is GuardType<T[0]> => args.every(arg => arg(obj));
}

// Doesn't work
const combinedN: (obj: any) => obj is number = combineTypeGuardsN(
    (obj: unknown): obj is number | string => true,
    (obj: unknown): obj is number | boolean => true,
);

/**************************************************************************/

type UglyGuardType<T extends Array<(obj: any) => obj is unknown>> = 
   T extends [(obj: any) => obj is infer U, ...infer Rest extends Array<(obj: any) => obj is unknown>]
        ? U & UglyGuardType<Rest>
        : unknown;

function uglyCombineTypeGuardsN<T extends Array<(obj: any) => obj is unknown>>(...args: T) {
    return (obj: any): obj is UglyGuardType<T> => args.every(arg => arg(obj));
}

const uglyCombinedN: (obj: any) => obj is number = uglyCombineTypeGuardsN(
    (obj: unknown): obj is number | string => true,
    (obj: unknown): obj is number | boolean => true,
);

https://tsplay.dev/m0A0RW

[typescript-bot]

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