3.4 regression for type argument inference

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 })
    })
}

Anders Hejlsberg (@ahejlsberg)

CC Anders Hejlsberg (@ahejlsberg) Wesley Wigham (@weswigham) Ryan Cavanaugh (@RyanCavanaugh)

Matt Bierner (@mjbvz)

Matt Bierner (@mjbvz)

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'.

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

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

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.

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>

Navigation Menu

Repository navigation

3.4 regression for type argument inference #30390

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

3.4 regression for type argument inference #30390

Description

Activity

DanielRosenwasser commented on Mar 14, 2019

DanielRosenwasser commented on Mar 14, 2019

RyanCavanaugh commented on Mar 14, 2019

weswigham commented on Mar 14, 2019

DanielRosenwasser commented on Mar 14, 2019

ahejlsberg commented on Mar 27, 2019

16 remaining items

MikeJerred commented on Feb 13, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions