Type flow analysis in constructor not working properly with strictPropertyInitialization

[paul-go]

TypeScript Version: 3.2.0-dev.201xxxxx

Search Terms:
strictNullChecks
constructor

Code

(This may actually be two separate issues.)

// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.

class X
{
	constructor()
	{
		// Commenting and uncommenting this supposedly no-op line
		// causes a definite assignment error to be reported on the private x field.
		if (this instanceof X) { }
		false && (this.x = null!);
		
		// Possibly related, but statically verifyable truthy expressions
		// don't cause definite assignment verification to be fulfilled.
		
		// Causes the definite assignment condition to be fulfilled.
		true && (this.x = null!);
		
		// *Should* cause the definite assigment condition to be fulfilled,
		// but does not appear to do so.
		"I'm true" && (this.x = null!);
		1 && (this.x = null!);
	}
	
	private x: X;
}

Associated tsconfig file:

{
	"compilerOptions": {
		"module": "commonjs",
		"target": "es2017",
		"lib": [
			"es7",
			"es2017",
			"es2017.object"
		],
		"inlineSourceMap": true,
		"inlineSources": true,
		"noEmit": true,
		"noImplicitThis": true,
		"strict": true,
		"strictNullChecks": true,
		"rootDir": "./",
		"baseUrl": "./",
		"stripInternal": true
	}
}

Expected behavior:
Uncommenting the if (this instanceof X) { } line should have no effects on the rest of the method. I would also expect expressions whose computed values are statically verifiable to contribute to type flow analysis, rather than just the "true" / "false" literals. Of course there is a very long tail to how far this could be taken, but as it stands, my original intent of using truthy literals as compilation constants (that are replaced in the build process) can't be realized with strictNullChecks:

"__DEBUG__" && this.someFieldOnlyVisibleDuringTests = ...

(Unless of course I just exploit this bug behavior)

Actual behavior:
Covered above.

Playground Link:
(I'm fairly sure strictNullChecks aren't an option in the playground)

Related Issues:

[paul-go]

Updates: After more poking around, it appears that any conditional in a constructor that checks for this instanceof WhateverTheCurrentClassIs, regardless of it's contents, basically disables the entire definite assignment checking process.

[ahejlsberg]

I'm unable to reproduce this behavior with the current master branch or the playground, even with verbatim copies of your example and tsconfig.json file. I'm not seeing any errors on the private x property, regardless of whether the line with the instanceof check is commented out.

[ahejlsberg]

I'm fairly sure strictNullChecks aren't an option in the playground

The are indeed an option. Just click Options, check the box, and click Options again to make the drop down go away.

[paul-go]

I appeared to have misreported the issue. The actual error occurs when strictPropertyInitialization is on. It also appears that the case is broader: this instanceof AnythingValid seems to trigger the bizarre behavior.

Here is the relevant playground link:

https://www.typescriptlang.org/play/#src=class%20Foo%0D%0A%7B%0D%0A%09constructor()%0D%0A%09%7B%0D%0A%09%09%2F%2Fif%20(this%20instanceof%20Boolean)%20%7B%20%7D%0D%0A%09%7D%0D%0A%0D%0A%09readonly%20y%3A%20number%3B%20%0D%0A%09readonly%20z%3A%20string%3B%0D%0A%7D%0D%0A

[ahejlsberg]

Yeah, that looks like an issue in the control flow analyzer.