Compiler option "noImplictThis" should imply stricter type checks

[PetaSoft]

Search Terms

TypeScript 3.9.2, compiler options noImplicitThis, noImplicitAny, strict, allwaysStrict
type checking

Suggestion

Currently, a class method without a this parameter can be assigned to a variable of a function type that has a this: void parameter. This should not be possible if compiler option noImplicitThis is set to true, because when the variable with function type is called this can be equal to undefined and the class method body can have calls like this.name = value which causes a runtime error (see Example 1 below).
Furthermore, a function with this: any parameter can currently be assigned to a variable with the same type but a this: void parameter. Calling that variable once again can cause a runtime error because of the same reason as above. This should not be possible even with noImplicitThis set to false (see Example 2 below).
I tested these cases with VS Code 1.45, TypeScript 3.9.2, and compiler options noImplicitThis, noImplicitAny, strict, and allwaysStrict set to true (beside other options).

noImplicitThis in the current implementation is more a kind of noImplicitAnyThis: Functions without a this parameter, and which are not methods, cannot use this in their body (this would be implicitly any), but methods without a this parameter can use this in their body, and their method signature does not even implicitly get a this parameter assigned by the compiler or language server (this would be implicitly assigned the type of the class).

Please change the behaviour of compiler option noImplicitThis or add another compiler option strictThis which implies the above mentioned stricter this type checks.

Examples

• Example 1 (adaption of an example found in the TypeScript Handbook).

interface UIElement {
  addClickListener(onclick: (this: void, e: ErrorEvent) => void): void;
}
class Sphere implements UIElement {
  addClickListener(onclick: (this: void, e: ErrorEvent) => void): void {
    // Raises "TypeError: Cannot set property 'info' of undefined"
    onclick(new ErrorEvent('Event Error'));
  }
}
class Handler {
  info: string | undefined;
  onClickBad(e: ErrorEvent) {
    // oops, used `this` here. using this callback would crash at runtime
    this.info = e.message;
  };
}
let h = new Handler();
const uiElement: UIElement = new Sphere();
// the following does not cause a compile time error but a run time error!
uiElement.addClickListener(h.onClickBad); 

• Example 2

let funcAny = function(this: any) {
  this.name = 'Microsoft';
};
let funcVoid : (this: void) => any = funcAny;  // does not cause a compile time error!
funcVoid();  // causes a run time error!

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[DanielRosenwasser]

Duplicate of #7968.