Allow overriding of instance methods with staticmethods or classmethods?

[sharkdp]

As a follow up to #4341, this ticket tracks the open question about whether or not to allow the following override (and similar cases with classmethod, or in reverse):

class Base:
    def f(self, x: int) -> None:
        ...

class Sub(Base):
    # ty: invalid-method-override
    @staticmethod
    def f(x: int) -> None:
        ...

See #4341 (comment) for an explanation of why this is not sound (and why we might want to allow it anyway).

[sharkdp]

Thinking about this some more: we do, in fact, already allow the reverse direction. ty emits no error here:

class Base:
    @staticmethod
    def f(x: int) -> None:
        ...

class Sub(Base):
    def f(self, x: int) -> None:
        ...

However, @carljm's argumentation in #4341 (comment) also applies to this case:

def call_method(cls: type[Base]):
    cls.f(1)

call_method(Base)  # okay
call_method(Sub)  # no ty diagnostic, but fails at runtime!

This is what I didn't realize before: to make this consistent, we can either disallow the staticmethod/classmethod -> instance method override, or allow the instance method -> staticmethod/classmethod override. The current situation is definitely inconsistent.

I think I'm now also leaning towards just allowing all of them. I don't want to introduce even more Liskov diagnostics.

[AlexWaygood]

I think I'm now also leaning towards just allowing all of them. I don't want to introduce even more Liskov diagnostics.

one option is for banning instance vs static/class method overrides to be a separate, opt-in rule for folks who want additional soundness in this regard