
I prefer that solution over an override decorator.
If I read the proposal correctly, the point of the `@override` decorator is not to enforce incompatible method override check. I believe most type checkers already enforce that, as you pointed out. Adding another decorator for that purpose would be obviously redundant. Instead, the purpose of the decorator is to catch cases where the user intends to do an override, but actually did not. For example, ``` class Base: def foo_renamed(self) -> int: ... class Derived(Base): def foo(self) -> int: ... ``` The above code snippet does not contain any incompatible method override issue. It is possible that `Base.foo_renamed()` and `Derived.foo()` are just two completely unrelated methods. But there's also the possibility that `Derived.foo()` does intend to override something in the base class -- perhaps that method was called `Base.foo()` originally but the developer has renamed `Base.foo()` to `Base.foo_renamed()` at some point yet forgets to update the corresponding method name in `Derived`. The proposed `@overload` decorator provides a way to differentiate between these two scenarios, so the type checker can emit a warning when `Derived.foo()` is actually introducing a new method name instead of overriding any pre-existing methods. - Jia