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.

Inizia esaminando la documentazione di TypeScript 4.3 su override e --noImplicitOverride collegata nell’issue, quindi studia l’esempio di interfaccia alla base della motivazione e la regola TSLint personalizzata esistente. Definisci se le interfacce debbano usare override o una nuova parola chiave, e stabilisci le diagnostiche previste per i membri opzionali rinominati prima di proporre l’implementazione e i test.