3.4 regression for type argument inference

[DanielRosenwasser]

Found trying to compile VS Code at https://github.com/Microsoft/vscode/blob/1ce2b64abb08ed7998a5a6697ba0248a51934605/src/vs/workbench/services/textfile/common/textFileService.ts#L294-L338

Isolated repro:

function blah(): Promise<{ success: boolean }> {
    return Promise.resolve(100).then(() => {
        if (Math.random()) {
            return {
                success: true
            }
        }
        return Promise.resolve({ success: false })
    })
}

[DanielRosenwasser]

CC @ahejlsberg @weswigham @RyanCavanaugh

[DanielRosenwasser]

@mjbvz

[RyanCavanaugh]

Error is

clipboard.ts:2     return Promise.resolve(100).then(() => {
                                                    ~~~~~~~
  TS2345: Argument of type '() => Promise<{ success: false; }> | { success: true; }' is not assignable to parameter of type '(value: number) => { success: false; } | PromiseLike<{ success: false; }>'.
    Type 'Promise<{ success: false; }> | { success: true; }' is not assignable to type '{ success: false; } | PromiseLike<{ success: false; }>'.
      Type '{ success: true; }' is not assignable to type '{ success: false; } | PromiseLike<{ success: false; }>'.
        Type '{ success: true; }' is not assignable to type '{ success: false; }'.
          Types of property 'success' are incompatible.
            Type 'true' is not assignable to type 'false'.

[weswigham]

Ah, yes, the common bug of us inferring literal types where we really shouldn't.

[DanielRosenwasser]

(thanks, I had to run to catch a bus)

[ahejlsberg]

We now make inferences from generic return type positions (#29478), so the return statements have the contextual type { success: boolean } | PromiseLike<{ success: boolean }> where previously they had none. Because of the contextual type we infer more specific return expression types { success: true } and Promise<{ success: false }>, which in turn means we end up inferring both { success: true } and { success: false } for the TResult1 type variable of then. Neither of those is a subtype of the other, so we pick just one and subsequently end up with an error.

A simpler example of the same issue:

declare function capture<T>(f: () => [T]): [T];

let x1: [{ success: boolean }] = capture(() => {
    return Math.random() ? [{ success: true }] : [{ success: false }];
})

Interestingly, this very similar example doesn't have an issue:

let x2: [{ success: number }] = capture(() => {
    return Math.random() ? [{ success: 0 }] : [{ success: 1 }];
})

The reason is that a contextual type number doesn't cause us to infer literal types. Only when the contextual type itself contains literal types do we infer literal types. And that brings us to the core issue: For number and string we have a distinct non-literal type representing the entire domain, whereas boolean is indistinguishable from the union false | true (and the same is true for enum literal types).

We could attempt to track whether all occurrences of false and true in a contextual type originate in a reference to the boolean type and then not infer literal types, but it is non-trivial.

[MikeJerred]

I'm not sure if this is the same issue or not:

class Base {}

class Foo<T> extends Base {
  constructor(value: T, fn: (value: Foo<T>) => void) { super(); }
}

const foo = new Foo(5, (f: Foo<number>) => {});
// foo has type Foo<5>
const bar = new Foo(5, (f: Foo<number> & Base) => {});
// bar has type Foo<number>