Bug: Control flow type analysis regression.

[vagarenko]

TypeScript Version: 2.0.3

This code compiles in TS 1.8 but not in 2.0.3
Code

class A { }
class B { constructor(public b: number) {} }

function foo(x: A | B): number | boolean {
    if (x instanceof A) { return true; }
    else if (x instanceof B) { return x.b; }
    //                                  ^ Property 'b' does not exist on type 'never'.
};

This error only appears if class A has no fields or methods,
if I add a field or a method the error disappears (but not constructor).

[ahejlsberg]

This is working as intended. The problem here is that structurally A and B are the same type (because constructors don't affect the instance type). So, the x instanceof A check also eliminates B. As you mention, it will behave correctly as long as there is some structural difference between A and B, so that is the workaround.

That said, this is not the first time someone has reported this issue. In the particular case of instanceof it would be nice to somehow treat A and B nominally as that would more accurately reflect what happens a run-time.

[vagarenko]

@ahejlsberg
I don't understand. How can they be structually identical if type B has field b: number and type A has none?

Why then this code compiles fine:

class A { constructor(public b: number) {} }
class B { constructor(public b: number) {} }

function foo(x: A | B): number | boolean {
    if (x instanceof A) { return true; }
    else if (x instanceof B) { return x.b; }
};

?
There is no structual difference between A and B here.

Also, as I said this worked fine in Typescript 1.8 and it isn't mentioned in Breaking Changes page.

[ahejlsberg]

Sorry, I missed the public modifier in the constructor in your first example. You're right, A and B are not structurally identical. Rather, B is a subtype of A.

There are more details on the changes since 1.8 in #10194 and #10216. The core issue we have is that we use structural subtype relationships to reason about instanceof which isn't always correct. Specifically, it produces different results in cases where classes that don't extend each other are structurally identical or structural subtypes. We've been discussing ways to fix this but haven't yet done so.