Add override / noImplicitOverride support for interfaces

Suggestion

🔍 Search Terms

noImplicitOverride interface override

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

📃 Motivating Example

The new override keyword in TS4.3 works for classes but not for interfaces.
Would be great to have it also available for interfaces. As interfaces are technically not overridden, alternatively a new keyword like implement could be introduced (Java, for example, uses override for classes and interfaces though)

💻 Use Cases

What is the advantage of override / noImplicitOverride for interfaces? Consider this case:

interface ISomething {
  doSomething?: () => void;
}

class Something implements ISomething {
  doSomething: () => {console.log("Something")}
}

If you rename doSomething() in the interface to doSomethingElse(), this would not throw an TS error, since it is optional and therefore doesn't have to be implemented. The implementing class would still have a doSomething() method which never gets executed.

If I would be forced to do something like this, TS could throw an error if I rename doSomething in the interface:

class Something implements ISomething {
  override doSomething: () => {console.log("Something")}
}

Currently I am using a custom TSLint rule via eslint but TSLint is already deprecated and also the rule stopped working with TS 4.3.
An according ESLint is not planned for this.
Anyhow, I think this check could be done directly in TS.

Start by reviewing the TypeScript 4.3 override and --noImplicitOverride documentation linked in the issue, then study the motivating interface example and the existing custom TSLint rule. Define whether interfaces should use override or a new keyword, and establish the expected diagnostics for renamed optional members before proposing implementation and tests.