this subclass inference problem

[mjbvz]

From Jonathan Edwards (@JonathanMEdwards) on May 5, 2017 19:19

• VSCode Version: Code 1.12.1 (f6868fce3eeb16663840eb82123369dec6077a9b, 2017-05-04T21:18:32.269Z)
• OS Version: Darwin x64 16.5.0
• Extensions:

Extension	Author	Version
ExtensionUpdateCheck	HookyQR	0.0.2
vscode-npm-script	eg2	0.1.9
auto-close-tag	formulahendry	0.3.12
backspace-plusplus	jrieken	0.0.15
Theme-MaterialKit	ms-vscode	0.1.4
debugger-for-chrome	msjsdiag	3.1.1
theme-black-plus	none	0.0.1
theme-visualstudio black	none	0.0.1

---

Steps to Reproduce:

class A {
  foo = 0;
  method() {
    if (this instanceof B) {
      this.foo;
    } else {
      this.foo;
    }
  }
}
class B extends A {
}

Produces error:

'Property 'foo' does not exist on type 'never'.'

Copied from original issue: microsoft/vscode#26071

[mjbvz]

Using TS 2.3.2, I confirmed this error in a js file with checkJs enabled

[DanielRosenwasser]

We narrow out A because B is structurally identical to A. This is an awkward sort of problem that applies to TypeScript as well.

[JonathanMEdwards]

I see. adding
private nominal() { }
to the subclass fixes the problem

[JonathanMEdwards]

But why does this work?

class A {
  foo = 0;
  method() {
    let t = this; // <----- type magic
    if (t instanceof B) {
      this.foo;
    } else {
      this.foo;
    }
  }
}
class B extends A {
}

[DanielRosenwasser]

TypeScript doesn't catch that t and this refer to the same entity because it would require analysis for aliasing of the runtime value. So if you look at t in the else branch, you'll have never, but this will appear unchanged in its type.

[jbrownson]

Using typescript 2.5.3 w/ noImplicitAny, strictNullChecks

Here's another variation of this problem:

export class Foo {x: number}
export class Bar {}
export function f(x: Foo | Bar) { x instanceof Bar || x instanceof Foo }

You get an error on the x in x instanceof Foo because its inferred type is never. The fundamental problem in both my and Jonathan's case seems to be related to conflating structural and nominal typing. There is some structure to the value that Typescript isn't considering, namely the constructor.

Another way to think of it is the first instanceof does indeed prove that x conforms to the structural type of either Foo or Bar, but it doesn't prove that in the second clause of the || that that x doesn't still have that structure, but Typescript assumes it does.

It may be interesting to note that this is distinct from the behavior of typeof:

export function g(x: string | number) { typeof x === "string" || x / 2 }

This code correctly type checks because it isn't possible for x to be a string in the second clause of the || because the typeof x === "string" check not only proves that x is a "structural" string in the first clause, but it proves that it can't be in the second clause as opposed to the instanceof behavior above.

Also, funny running into you here w/ the same bug I was about to report Jonathan, howdy :)

[jbrownson]

It looks like there is a long history here:
#8168
#8503
#10934
#11245
#11664
#16693
#18276

Looks like a long time ago it worked as I suggested above, but it was moved to work this way. The new feature to not allow instanceof on things that can't be objects made some code that had been working break, though I now realize it had inferred some really strange types before so I'd rather have it break I suppose.

Anyway I've left enough notes here, I'm going to go ahead and work around it by making all of the classes structurally different w/ some dummy functions.