New flag `--noImplicitAbstractOverride` which mandates the use of `override` when implementing an abstract method

Suggestion

🔍 Search Terms

flag override implicit noImplicitOverride abstract

✅ 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

Currently, when --noImplicitOverride is enabled, overriding (or implementing) an abstract method does not require the use of keyword override.

I suggest adding a new flag --noImplicitAbstractOverride, which, when enabled in conjunction with --noImplicitOverride, will also require override when implementing an abstract method.

📃 Motivating Example

In issue #44457, @RyanCavanaugh explained the rationale behind --noImplicitOverride not covering implementing abstract methods is that --noImplicitOverride is designed to prevent typos. Since not implementing an abstract method will already result in an error, it is not necessary to let --noImplicitOverride also cover that case.

However, that is only one use case for the override keyword. In fact, I don’t think --noImplicitOverride has ever helped me catch any typo bugs that way, thanks to the modern IDE I use, which automatically fills in method names when I am about to override a method. (I am not saying it is not helpful, though.)

In my opinion, one of the most valuable functionality that override provides is explicitly telling the programmers which methods are from the the super class and which methods are new. This is especially valuable when reading code of a class in a complicated inheritance tree.

Ideally, I think such behavior should be a part of --noImplicitOverride. However, since that ship has already sailed, it seems a new flag is required.

---

Side note: I do realize that implementing an abstract method is technically not really overriding anything. However, by this line of reasoning, when implementing abstract methods override should be completely disallowed instead of optional.

---

(Hey, the person giving me thumbs down, it will be better if you can come out and explain why you don’t agree with me.)

👇

[diesal11]

I found myself here after having enabled --noImplicitOverride thinking this would be the default behaviour. Would love to see this implemented in future.

[frank-weindel]

I agree with this. I think the override keyword more than anything else helps inform developers that a method and its signature are specified in the base class and hence its implementation may have some influence on the class that is not readily apparent by just looking at the sub-class implementation. While override may not be actually what you’re doing in an abstract class, I still think its relatively intuitive.