'this' type cannot be compared with subclasses

[aimozg]

TypeScript Version: 2.3.2

Code

class Superclass {
	test(b:Subclass):boolean {
		let x;
		x = this == b; // TS2365
		x = this as Superclass == b; // workaround
		x = this instanceof Subclass && this == b;
		return x;
	}
}
class Subclass extends Superclass {
	public subfield=0;
}

Produces error
TS2365:Operator '==' cannot be applied to types 'this' and 'Subclass'.
Same for !=, ===, !==.

Possibly related to #15615 .

[mhegazy]

this is the type of the most derived class at the time of instantiation, that can be something else than SubClass, consider class SubClass3 extends SubClass .. .

if you intend to use this, then type it as such:

class Superclass {
	test(b:this):boolean {
		let x;
		x = this == b; // OK
		return x;
	}
}

[aimozg]

@mhegazy But I don't even use this as a type. I just have a method in a superclass that is aware of subclass existance and want to perform a strict reference equality check. And the method parameter must be Subclass.

class Superclass {
	test(b:Subclass):boolean {
		return this == b || b.subfield>0; // TS2365
	}
}

[aimozg]

class Superclass {
	isMeOrPositive(b:Subclass):boolean {
		return this == b || b.subfield>0; // TS2365
	}
}
class Subclass extends Superclass {
	constructor(public subfield:number){
		super();
	}
}
class Grandchild extends Subclass {
	constructor(subfield:number,public name:String){
		super(subfield);
	}
}
let a = new Superclass();
let b = new Subclass(0);
let c = new Grandchild(10,"c'");
for (let i of [a,b,c]) console.log(i.isMeOrPositive(b),i.isMeOrPositive(c));
// false true
// true true
// false true

If that compiler error is intended behaviour, what kind of situation it tries to prevent?

[RyanCavanaugh]

@mhegazy I can't figure out why this behavior is desirable, though I do understand why it happens. What's conceptually different between this and the code below?

var x: string | number = <any>null;
var y: number | boolean = <any>null;
x === y;

[RyanCavanaugh]

This doesn't seem frequently-hit, and the rules for comparability are complex enough already that I don't think it's worthwhile to complicate them further to account for this. The semantics here are consistent with other places where we disallow ===, even though it's known to generate false positives.