Can we get rid of the

override

keyword? Do we really need it?

It prevents a) accidental overriding, and b) failing to override when you meant to do so. A classic from Java is to write

public boolean equals(Foo foo)

and think you have overridden equals when you haven't.

b) failing to override when you meant to do so.

wouldn’t the compiler catch that for you?

Not if you were intending to override a non-abstract method like

equals

. Remember there are

open class

as well as `abstract`/`sealed`.

I really love it because it makes it clear, which function is actually implemented and overridden. Biggest "problem" is an abstract/open function which was removed later, but you still have the

@Override

annotated dead function in your code bais

It doesn't bother me particularly that

override

means "implements or overrides". The important bit is that it allows the compiler to guarantee that the signature is defined on a supertype (and its absence allows the compiler to guarantee that the signature is not defined on a supertype). Is there a better short term that conveys that?

Yeah, doesn’t bother me either, but this thread just made me realize this explicitly. I think it’s good that a single keyword can be used for both purposes - and from the implementor’s point of view, there’s no difference, it’s just about the compiler.

On the subject of overrides, I note that if we implement two interfaces that have the same named function, we can only override that function once. By contrast, other languages, such as C#, allow something like this:

interface Ia {
    fun foo()
}

interface Ib {
    fun foo()
}

class C : Ia, Ib {
    override fun Ia.foo() {  // Not valid Kotlin
        println("a")
    }

    override fun Ib.foo() {  // Not valid Kotlin
        println("b")
    }
}

Kotlin inherits Java's behaviour with respect to interfaces. This means that we can only implement two interfaces with the same-named function if that function has equivalent meaning between the two interfaces. Sometimes, two interfaces can have two functions that have a totally different intention but their names match purely by coincidence. C# allows us to write different implementations for each such function. In Kotlin, we need to do it in a roundabout way, e.g. by inserting an adaptor interface between one of the interfaces and the implementing class.

given that Kotlin compiles to JVM bytecode and is compatible with Java's object model, there's no way around that