instanceof typeguard fails if classes have similar structure

[basarat]

TypeScript Version:

1.8.x and nightly

Code

class C1 { item: string }
class C2 { item: string[] }
class C3 { item: string }

function Foo(x: C1 | C2 | C3): string {
    if (x instanceof C1)
        return x.item;
    else if (x instanceof C2)
        return x.item[0];
    else if (x instanceof C3)
        return x.item; // Error property item does not exist on C2
}

Expected behavior:
Code should compile

Actual behavior:
Code has an error as shown

More

The following works i.e. if C1 and C3 differ in structural compatibility:

class C1 { item: string }
class C2 { item: string[] }
class C3 { items: string }

function Foo(x: C1 | C2 | C3): string {
    if (x instanceof C1)
        return x.item;
    else if (x instanceof C2)
        return x.item[0];
    else if (x instanceof C3)
        return x.items; // Ok
}

🌹

[ivogabe]

I'm afraid this is by design. I get a lot trouble with this too, so I hope this could be changed. Adding a brand to one of the classes fixes it, but I don't like that approach very much. I think x instanceof C1 should only remove C1 in the else branch, not both C1 and C3, or it shouldn't remove any types in the else branch. The current behavior doesn't match what happens at runtime, for instance this does not give any compile error:

function Foo(x: C1 | C2 | C3): string {
    if (x instanceof C1)
        return x.item;
    else
        return x.item[0];
}

The type of x is C2 in the else block, but at runtime it could also be C3.

[yortus]

I've also run into this problem, and wish that the compiler behaviour could be brought more into line with what happens at runtime. It's not specific to instanceof or classes, it's really just about the structural similarity of the types in the union. E.g., this works fine at runtime, but fails at compile time:

type UnaryFunction = (a: any) => any;
type BinaryFunction = (a: any, b: any) => any;
function isUnaryFunction(fn: Function) : fn is UnaryFunction {
    return fn.length === 1;
}
function isBinaryFunction(fn: Function) : fn is BinaryFunction {
    return fn.length === 2;
}
function foo(fn: UnaryFunction | BinaryFunction) {
    if (isBinaryFunction(fn)) {
        fn(1, 2);   // OK: fn is BinaryFunction here
    } else {
        fn(1);      // ERROR: Cannot invoke an expression whose type lacks a call signature
    }
}

I think the problem is similar to @basarat's, because from a structural typing viewpoint, a UnaryFunction is just a subtype of a BinaryFunction, triggering different narrowing behaviour than if the types were structurally independent. However there is no subtype relationship according to the runtime checks in isUnaryFunction and isBinaryFunction.

---

Here is another case that brings up this type guard behaviour because the compiler sees the types as structurally related. Consider a function that takes either (a) an options object, where all options are optional, or (b) a function that returns an options object:

interface OptionsObject {
    option1?: string;
    option2?: number;
}
interface OptionsFunction {
    (): OptionsObject;
}
function isOptionsObject(opts: OptionsObject | OptionsFunction) : opts is OptionsObject {
    return opts && typeof opts === 'object'; // definitely not a function
}
function bar(opts: OptionsObject | OptionsFunction) {
    let option1: string;
    if (isOptionsObject(opts)) {
        option1 = opts.option1 || 'none';   // ERROR: no option1 on OptionsObject|OptionsFunction
    } else {
        option1 = opts().option1 || 'none'; // OK
    }
}

This also works at runtime but fails at compile time. The compiler sees OptionsFunction as just a special case of OptionsObject, because structurally it is. But it is not a subtype according to the runtime check in the type guard.

---

I have learned how to spot and work around these cases now. But that involves taking valid runtime code, and rearranging it just right so the compiler won't complain. It's a (rare) case where the tool is fighting me rather than helping me. Probably also quite unintuitive for beginners.

[yortus]

@basarat here is a version of your example without instanceof or classes. It has the same error as your example, which is why I think this is about the structural type similarity and not related to the presence of instanceof or classes:

interface C1 { item: string }
interface C2 { item: string[] }
interface C3 { item: string }

function isC1(c: C1 | C2 | C3): c is C1 { return /*some test*/ }
function isC2(c: C1 | C2 | C3): c is C2 { return /*some test*/ }
function isC3(c: C1 | C2 | C3): c is C3 { return /*some test*/ }

function Foo(x: C1 | C2 | C3): string {
    if (isC1(x))
        return x.item;
    else if (isC2(x))
        return x.item[0];
    else if (isC3(x))
        return x.item; // ERROR
}

[yortus]

Another example, this time with typeof, that's maybe the same problem? Since Function is a subtype of Object. But isn't string also a special case of Object structurally? Not sure about this one...

function ok(x: string | Object) {
    if (typeof x === 'string') {
        x // string
    }
    else {
        x // Object
    }
    if (typeof x === 'object') {
        x // Object
    }
    else {
        x // string
    }
}


function fail(x: Function | Object) {
    if (typeof x === 'function') {
        x // Function | Object
    }
    else {
        x // Function | Object
    }
    if (typeof x === 'object') {
        x // Function | Object
    }
    else {
        x // Function | Object
    }
}

[falsandtru]

+1 this behavior is buggy.

[falsandtru]

from #6589 because it merged into this issue.

---

Type narrowing strategy for most closest type selection

Narrowing to the closest runtime type by instanceof operator:

class A<T> {
    prop: T;
}
class B<T> extends A<T> {
}
class C extends B<any> {
}

var x: A<string> | B<any> | C;
if (x instanceof A) {
    x; // closest type is A, now B
}
if (x instanceof B) {
    x; // closest type is B, now B
}
if (x instanceof C) {
    x; // closest type is C, now B
}
if (x instanceof Object) {
    x; // closest type is A, now B
}
if (x instanceof Array) {
    x; // no closest type, must be contextual type `A<string> | B<any> | C`
}

Motivation

Sometimes we must check the instance type instead of pattern matching. TypeScript should provide the way that select the most closest type for alternate method of pattern matching.

// maybe monad
  public bind<U>(f: (val: T) => Maybe<U>): Maybe<U> {
    return new Maybe<U>(() => {
      const m: Just<T> | Nothing | Maybe<T> = this.evaluate();
      if (m instanceof Just) {
        return f(m.extract());
      }
      if (m instanceof Nothing) {
        return m;
      }
      if (m instanceof Maybe) {
        return (<Maybe<T>>m).bind(f); // `m` is `Nothing | Maybe<T>`, should be `Maybe<T>`
      }
      throw new TypeError(`ArchStream: Maybe: Invalid monad value.\n\t${m}`);
    });
  }

Searching and showing of all derived types is useless and too complex when there are many derived types, and TypeScript should reduce those unnecessary costs for optimization.

class A<T> {
    prop: T;
}
class B<T> extends A<T> {
}
class C extends B<any> {
}

var x: A<string> | B<any> | C;
if (x instanceof A) {
    x; // this scope narrowed by A, B and C are useless, but x is B
}

In general, sets of types must narrow by operations, but instanceof operator widen types. Roles and effects of typings for abstraction is reducing of calculation size based on sets size.

class A<T> {
    a: T;
}
class B<T> extends A<T> {
    b: T;
}
class C extends A<any> {
    c: any;
}

var x: A<string> | B<string> | C;
if (x instanceof A) {
    x; // x should narrow to A of the most closest type from `instanceof` operator specified type.
    // if you want B or C, it should narrow by those types.
}

instanceof operater compare constructors in js engine, but TypeScript compiler compare structural types. It is mismatch behavior.