Improved union/intersection type inference

[Anders Hejlsberg (ahejlsberg)]

This PR improves type inference involving source and target sides that are both union or intersection types. When inferring from a type S to a type T, if S and T are both union types or both intersection types, we first reduce S and T by removing constituents that are matched by a constituent in the other type. For example, when inferring from string | string[] to string | T, we reduce the types to string[] and T, thus inferring string[] for T.

An example:

type Maybe<T> = T | void;

function isDefined<T>(x: Maybe<T>): x is T {
    return x !== undefined && x !== null;
}

function isUndefined<T>(x: Maybe<T>): x is void {
    return x === undefined || x === null;
}

function getOrElse<T>(x: Maybe<T>, defaultValue: T): T {
    return isDefined(x) ? x : defaultValue;
}

function test1(x: Maybe<string>) {
    let x1 = getOrElse(x, "Undefined");         // string
    let x2 = isDefined(x) ? x : "Undefined";    // string
    let x3 = isUndefined(x) ? "Undefined" : x;  // string
}

function test2(x: Maybe<number>) {
    let x1 = getOrElse(x, -1);         // number
    let x2 = isDefined(x) ? x : -1;    // number
    let x3 = isUndefined(x) ? -1 : x;  // number
}

Fixes #2264.
Fixes #4212.
Fixes #5417.
Fixes #5456.

[Nathan Shively-Sanders (sandersn)]

How about

return forEach(target.types, t => isTypeIdenticalTo(source, t) || undefined);

[Anders Hejlsberg (ahejlsberg)]

Definitely an option, but not quite as efficient. I will keep what's there.

[Nathan Shively-Sanders (sandersn)]

👍

[Daniel Rosenwasser (DanielRosenwasser)]

Can you break this into multiple lines?

[Mathias Lykkegaard Lorenzen (ffMathy)]

Use wordwrapping man.

[Marius Schulz (mariusschulz)]

Anders Hejlsberg (@ahejlsberg) You've got a little typo in your code example: isUndefined<T> should use or rather than and, shouldn't it? Just trying to avoid confusion here.

function isUndefined<T>(x: Maybe<T>): x is void {
    return x === undefined || x === null;
}

[Anders Hejlsberg (ahejlsberg)]

Marius Schulz (@mariusschulz) Yes indeed, thanks for catching that.

[Eugene Sadovoi (ENikS)]

Will this address issue mentioned in #3215 ?

[Anders Hejlsberg (ahejlsberg)]

Eugene Sadovoi (@ENikS) No, the two are unrelated.

[Asad Saeeduddin (masaeedu)]

Anders Hejlsberg (@ahejlsberg) Would inferring T more accurately in the following scenario be worthwhile:

interface A { a: any; }

function test<T>(arg: A & T): T { ... }

let result = test({a: "", b: 10});

The type of result is inferred as {}, although I would expect it to be inferred as {b: number}. Admittedly I don't have a very clear use case for this at the moment.

[Anders Hejlsberg (ahejlsberg)]

Asad Saeeduddin (@masaeedu) We could potentially explore that, but it could get complex and would require type inference to manufacture new types, neither of which I'm crazy about. Specifically, in your example, we'd have to manufacture a new type { b: number } and infer that for T. I think it is desirable to have the property that type inference never infers types that don't already occur in your code.