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

[sandersn]

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.

[aluanhaddad]

This is interesting. The problem I see with introduce an implicit this on interface types is that currently there is a lot of valuable flexibility in terms of how a member is implemented.
Given the declaration

interface I {
  m(x: number): void;
}
declare function f(o: I);

It can be implemented via a property or a method which is very handy if I am implementing it with an object literal, and want to retain the lexical this. I can implement I with a property m

this.value = 42;
f({
  m: (x) => console.log(this.value)
});

[mqudsi]

From #23749

I understand why TypeScript can't ditch this horrible behavior and evaluate the code sanely for reasons of backwards compatibility when changing JS file extensions to .TS, but as this is a common type-safety issue, I feel like TS should take measures to mitigate the issue.

TypeScript should be able to catch the unsafe usage of this in the example above (it fails the assertions).

Additionally, when typing this., the suggestions generated are for values based on the current scope instead of being any or something else, leading one to believe the code is correct.

Suggestions:

• Perhaps a --strictThis option generating an error when this.xxx is assigned to an object of a different type from the type of this in the current scope?
• A new keyword, e.g. self, the value of which binds to the current value of this that can be used instead.

[felixfbecker]

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.

Wouldn't it be possible to use the concrete type of the class/interface, i.e. this: Foo instead of this: this?

[mqudsi]

The more I think about it, the more I feel self is the answer here?

[mattmccutchen]

Duplicate of #7968 or vice versa?