In some circumstances a derived class is not assignable to its base class under --strictFunctionTypes

[JakeTunaley]

TypeScript Version: 3.1.0-dev.20180912

Search Terms: class extends assignability strict function types this

Code

class Base {
    private foo (): (this: this) => void {
        return (() => {}).bind(this);
    }
}

class Derived extends Base {
    private bar () {}
}

const value: Base = new Derived();

Expected behavior:
No errors.

Actual behavior:
The following error is generated on the constant value:

Type 'Derived' is not assignable to type 'Base'.
  Types of property 'foo' are incompatible.
    Type '() => (this: Derived) => void' is not assignable to type '() => (this: Base) => void'.
      Type '(this: Derived) => void' is not assignable to type '(this: Base) => void'.
        The 'this' types of each signature are incompatible.
          Type 'Base' is not assignable to type 'Derived'.
            Property 'bar' is missing in type 'Base'.

This only happens when --strictFunctionTypes is enabled.

This shouldn't happen because TS will not let you change a class' type signature in a way that breaks the extends clause - Derived is always a superset of Base.

Playground Link:
http://www.typescriptlang.org/play/#src=class%20Base%20%7B%0D%0A%09private%20foo%20()%3A%20(this%3A%20this)%20%3D%3E%20void%20%7B%0D%0A%09%09return%20(()%20%3D%3E%20%7B%7D).bind(this)%3B%0D%0A%09%7D%0D%0A%7D%0D%0A%0D%0Aclass%20Derived%20extends%20Base%20%7B%0D%0A%09private%20bar%20()%20%7B%7D%0D%0A%7D%0D%0A%0D%0Aconst%20value%3A%20typeof%20Base%20%3D%20Derived%3B

[RyanCavanaugh]

I think this is working as intended because the this in the return type is unsound to aliasing. Let's say we let you do this:

class Base {
	foo (): (arg: this) => void {
		return function () {
		}
	}
}

class Derived extends Base {
	foo (): (arg: this) => void {
		return function (arg) {
			arg.bar();
		}
	}

	bar() { }
}

const b = new Base();
const value: typeof Base = Derived;
// Typechecks OK, but crashes 
(new value()).foo()(b);

[JakeTunaley]

Okay, I think I understand. I'm expecting this to be an object instance unit type, when in reality it's just a special case of a type alias that takes the value of whatever its containing type is. That would also explain #26759.

I guess I understand why it's like that, because keeping track of object instances through code like the following would likely tank compiler perf:

// Assuming "ExactInstance" is some imaginary type that acts as an object instance unit type

class Foo {
    bar (arg: ExactInstance<this>) {}
}

const foo = new Foo();

function callBar (arg: ExactInstance<typeof foo>) {
    foo.bar(arg);
}

callBar(foo); // Fine
callBar(new Foo()); // Error
const foo2 = foo;
callBar(foo2); // Fine

Although if this behaves like a type alias, then the following is inconsistent:

class Foo {
    a (): this {
        // Error: Type 'Foo' is not assignable to type 'this'.
        return new Foo();
    }

    b (arg: this): this {
        return arg;
    }
}

const value = new Foo();
value.b(new Foo()); // But this call is completely fine...?

[sandersn]

The hidden type parameter Base<This> becomes invariant because of foo. This is inconsistent, but making the extends check stricter would break tons of code, so I think it has to stay this way.

The last example works because, for value, This=Foo when you say new Foo(). So the instantiated type of b: (arg: Foo) => Foo.