Completion does not work with instanceof operator (typescript)

[dbaeumer]

From @ltearno on January 15, 2016 13:57

With a typescript source file, when using the type guarded type inference, the auto completion does not work...

An example :

if(myObj instanceof MyClass) {
    myObj.ab// hit Ctrl+Space, the autocompletion will not trigger but should propose members of MyClass
}

Thanks !

Copied from original issue: microsoft/vscode#2046

[DanielRosenwasser]

@ltearno it depends on what the type of myObj is. instanceof don't work unconditionally - for instance, the type needs to be a subtype of the original type, and any technically isn't a subtype of MyClass.

[ltearno]

Thanks I get it ! Maybe there is something to add in the documentation

However, from the developper point of view, having guarded a code against "instanceof" guarantees that the variable is of the correct type. So what i don't get is WHY this behavior ? I am definitely missing something i guess... But wouldn't it be great if that code worked ?

Here is a demo piece of code :

class A {
}

class B extends A {
    test1() {
    }
}

class C extends A {
    test2() {
    }
}

let toto: A = null;
let titi: any = new B();

if(toto instanceof B){
    toto.test1(); // Here auto-completion works on toto.te...
}

if(titi instanceof B){
    titi.test1(); // Here auto-completion does NOT work on titi.te...
}

I have also tested that with user defined type-guards functions and the same behavior applies. But with user defined type-guards, the input parameter is declared of type 'any' so i really expect it to work for the titi variable.

Here is the code with the user defined type-guard function :

function isB(a: any): a is B {
    return true;
}

if(isB(toto)) {
    toto.test1(); // Here auto-completion works
}

if(isB(titi)) {
    titi.test1(); // Here auto-completion does NOT work
}

if(isB(<A>titi)) { // downcasting to A does not work, of course ;)
    titi.test1(); // Here auto-completion does NOT work neither
}

[DanielRosenwasser]

The idea is that with any you could use any property name you wanted and the compiler wouldn't complain to you. If we narrowed the type, then you'd be able to use strictly fewer properties.

That sounds ridiculous to most people at first, but the idea is that there's code out there like the following:

function f(x) {
    if (x instanceof Object) {
        // assume x is a well-known or "expected" type of object that's getting passed around
    }
    else if (typeof x === "number") {
        // x is a number
    }
    else {
        // assume x is a string or something
    }
}

You'll see this type of code in TypeScript that predates union types and TypeScript that's been ported over from JavaScript.

If we narrowed from any to Object then there's nothing you could really do with x. If you try to use any properties that aren't in Object, you'll get an error. When I experimented with letting instanceof type guards work on any, we found breaks in people's code pretty quickly.

We are considering changing the behavior for typeof type guards in #6015.

[ltearno]

Thank you, i completely get the point, that's perfect.

Le mar. 19 janv. 2016 à 19:30, Daniel Rosenwasser notifications@github.com
a écrit :

Closed #6527 #6527.

—
Reply to this email directly or view it on GitHub
#6527 (comment).