Type guard failures that become an intersection type

[falsandtru]

TypeScript Version: 2.0.0

Code

class A<T> {
 private _: T;
}
class B<T> {
 private _: T;
}
function f() {
 var o: A<void> | B<void> = new B<void>();
 if (o instanceof A) return o; // B<void> & A<any>, should be A<void>
}

Expected behavior:

A type of o narrowed by type guard is A<void>.

Actual behavior:

A type of o narrowed by type guard is B<void> & A<any>.

[yortus]

I'd say this follows from #8911/#9016.

o is narrowed to B<void> when you assign new B<void> to o. Then the compiler sees the o instanceof A as further narrowing and comes up with the intersection type.

I suspect the A & B type, which seems impossible in terms runtime behaviour, seems fine to the compiler which is just concerned about the structural intersection of the A and B types.

[yortus]

Note this comment in particular: #8911 (comment)

[mhegazy]

then options here are either never or A & B. never since this code can not execute if A and B are indeed disjoint, or A & B if B extends A at runtime. The first is too restrictive.

[falsandtru]

This problem seems to caused by declared type internal overwriting. This behavior should be a bug because following code works correctly.

class A<T> {
 private _: T;
}
class B<T> {
 private _: T;
}
function f() {
 var o: A<void> | B<void>;
 if (o instanceof A) return o; // A<void>
}

[mhegazy]

I am not sure i understand what you meant there. but the important difference between the two samples is the assignment...

var o: A<void> | B<void> = new B<void>();

// here o can only be `B<void>` and nothing else. no assignments has happened to o since it got `new B<void>()`

if (o instanceof A) return o; /// now how can we narrow B into A?

[falsandtru]

Mohamed Hegazy (@mhegazy) why do you think "working as intended" about that difference? The two samples should be a same narrowed type by type guard.

[yortus]

falsandtru (@falsandtru) assignments cause narrowing as per #8010. Then subsequent narrowing to an unrelated type narrows to the intersection of the two narrowed types as per #9031. According to those two rules, your example is indeed working as intended.

Your sample is a bit like the following, which produces the same intersection narrowed type:

class A<T> {
 private _: T;
}
class B<T> {
 private _: T;
}
function f() {
 var o: A<void> | B<void>;
 if (o instanceof B) {
 if (o instanceof A) return o; // B<void> & A<any>, should be A<void>
 }
}

[falsandtru]

I understood that behavior, but I'm not sure that behavior is a spec, or a bug.

[yortus]

Why would it be a bug? Control flow analysis can infer:

1. That o is a B throughout the body of f, since a B is assigned to o and there are no subsequent assignments that could change it to something else.
2. That the only way we could reach the guarded return o statement is if o is an A. And since o is already known to be a B, then o must be an A & B in that guarded clause.

[falsandtru]

Merging #9861.

class A<T> {
 private _: T;
}
class B<T> {
 private _: T;
}
function f() {
 var o: A<void> | B<void> = new B<void>();
 if (!(o instanceof B)) return o; // B<void>, should be A<void>
 o; // B<any>, should be B<boid>
}

Merging #9862.

class A<T> {
 private _: T;
}
class B<T> {
 private _: T;
}
function f() {
 var o: A<void> | B<void> = new A<void>();
 o instanceof A || o instanceof B;
 o; // A<any>, should be A<void> | B<void>
}

[mhegazy]

the first case is again because of the initialization. there is no way for o to be any thing but B. so checking !(o instanceof B) is really not meaningful here. so you have B, you take out B, what are you left with..

The same of the second case, it is A, it can not be anything else.

[falsandtru]

I see, I think we can close this issue. However, a compiler option for detection of this assignment (as initialization) type mismatch is helpful to avoid these confusing. A declared type shouldn't be wider than an assigned type with initialization in these CFA behaviors.