Repository: TypeScript
Issue: New flag `--noImplicitAbstractOverride` which mandates the use of `override` when implementing an abstract method
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

flag override implicit noImplicitOverride abstract

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->


## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-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.

<!-- A summary of what you'd like to see added or changed -->

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

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.

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

--- 

(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.)
>> 👇