This-function parameters must be specified in caller *and* callee, even for methods

This means that only very careful people will benefit from assignability checking (and therefore argument checking at call sites). (Due to contextual typing, code that uses a this-typed library will get improved body checking a lot of the time.)

Specifically, assignability checking only happens when this is explicitly declared by both sides.

Instead, class methods should implicitly have this: this unless declared otherwise.

Given the declarations:

declare let f: (this: string, x: number) => void;
declare class C {
  m(x: number): void;
  n(this: this, x: number): void;
}
declare let c: C;

Expected behavior:

c.m = f // error, 'this: string' is not assignable to 'this: string'
f = c.m // error, 'this: C' is not assignable to 'this: string'
f = c.n // error, 'this: string' is not assignable to 'this: C'
c.n = f // error, 'this: C' is not assignable to 'this: string'

Actual behavior:

c.m = f // no error
f = c.m // no error
f = c.n // error, 'this: string' is not assignable to 'this: C'
c.n = f // error, 'this: C' is not assignable to 'this: string'

Comments

The "this parameter" feature was designed this way to balance four concerns:

1. Backward compatibility with un-annotated code.
2. Compiler efficiency.
3. Consistency between class and interface this.
4. Quality of error checking.

As you can see, (4) took the biggest hit by requiring annotation on both the source and target of the assignment.

Backward compatibility

The problem with unannotated code is that we can't tell whether a function is intended to be called with or without this.

Functions

--noImplicitThis helps address this problem by forcing annotation of this parameters for functions.

TODO: Work through some examples.

Methods

Actually, for methods, we do have a pretty good idea that a method is not supposed to be removed from its class. Even if the class implements an interface, we the class methods should still be able to refer to class-private implementation details.

TODO: Work through some examples.

Interface consistency

The problem is that interfaces are frequently used to interact with objects instead of the class type itself. But interfaces are used in lots of other contexts as well. That means we can't infer intent with an interface, but if we don't add this: this to interface methods, we're left with a bad assignment problem:

interface I {
  m(x: number): void;
}
class C implements I {
  y = 12;
  m(x: number) {
    return this.y + x;
  }
}
let c = new C();
f = c.m;
f(); // error, this must of type 'C'
let i: I = c;
f = i.m;
f(); // ok, this is not annotated

"Assignment escape hatches" like this exist throughout TypeScript, but adding more is not a good thing.

Efficiency

Briefly, if every interface has a this type, then every interface will be generic, even in non-OO code. This causes the compiler to generate about double the number of types internally, which is slower and uses more memory than today.

Issue の代入可能性の例から始め、メソッド、クラス、インターフェイスで明示的な this パラメーターがどのように検査されるかを追跡します。完全な変更では、後方互換性、インターフェイスの一貫性、コンパイラーの効率、および TODO とマークされた未解決の例を考慮しながら、期待される 4 つのエラーが生成されます。