by the way, what would you think about an `impleme...

# language-proposals

[Pere Casafont]

by the way, what would you think about an implement keyword to be used instead of override when what you're "overriding" are actually interface or abstract methods?

[Pere Casafont]

just for having a clearer word, because we're not overriding any functionality in these cases

[spand]

With default methods that not really true is it?

[Pere Casafont]

right

[Russell Davis]

i like it. it makes things more clear when reading the code, and even provides some safety -- if something changes and your method actually becomes an override (but you previously had it as implement) you'd get a compiler error (maybe a subclass started implementing the same thing, and now you'd want to revisit your implementation)

[benleggiero]

override always felt… misleading, at best, when implementing an interface.

[karelpeeters]

Well it's way to late to change it now.

[benleggiero]

And that attitude is how a language like Java is supplanted by a language like Kotlin

[gildor]

It's just a word, what about cases when method actually overrides another?

[Pere Casafont]

well, then it's override

[Pere Casafont]

@Russell Davis I completely agree, I think both keywords have pretty distinct meanings

[gildor]

So if an interface converted to an abstract class every implementation should replace implement with override without any profit except different word?
It's like separation of extends/implements in Java but much worse.

[Pere Casafont]

like when you add a ? to a very used field, you have to revisit all its usages, that strictness is in kotlin's signature imho

[Pere Casafont]

also in my suggestion I said that abstract methods from abstract classes should still use the implements keyword, so that would apply only when you give a body to a method (what breaks my suggestion are default methods from interfaces, here I don't know which of both words would fit best)

[benleggiero]

If you are writing a method that none of the parents in the hierarchy tree ever implemented, meaning that yours is the only implementation, the keyword should be implement. Otherwise, if there was a previous implementation you want to override, the keyword should be override. This seems straightforward to me.

This achieves a similar strength as the override keyword, as now you know if an API changes and a method in an abstract class that used to have no implementation suddenly does, your code won't compile because you have not acknowledged this. Then you can decide if you want to use the "official" implementation by removing yours, or stick with your implementation by changing implement to override

[gildor]

like when you add a ? to a very used field

I see very big difference. I’m not just “add a `?`“, I changed type of property or signature of the method, so of course you should handle this case.
But in case of override/implement I don’t see any prevented bugs or any other profit from splitting those identical keywords.
Could you show me an example where it could prevent bugs or somehow help to a developer.
For me it’s just looks like an unnecessary point that reduces source compatibility without any profit

[gildor]

Otherwise, if there was a previous implementation you want to override, the keyword should be override. This seems straightforward to me.

Is not so straightforward for default methods.
Anyway, this looks like a change that complete breaks compatibility of all Kotlin sources

[benleggiero]

The term “break” is used too liberally around here… Yes, if we introduced a change like this in Kotlin 1.2.60, that would be terrible and would definitely go against the reasonable expectations of developers.
However, incrementing a major version number means “you make incompatible API changes”. If someone doesn’t want those changes, they don’t have to upgrade. It seems obvious to me.

If someone started trying to write Java code in their Kotlin file, it wouldn’t work because Kotlin has made so many major language advances after Java that they are incompatible.
Kotlin version 2.0 can be incompatible with code written for the 1.x compiler; that is why we use 1.x, and that is how semantic versioning works

https://semver.org

[gildor]

So, you want to propose this for 2.0 that even not under planning yet?
Also, don’t forget, nobody want to be python 3. So you can introduce some change for major version but still fail backward compatibility in a such dramatic way that you actually prevent people from update. Especially for a feature like that, where you don’t see obvious advantages but big parts of codebase become source incompatible.

[benleggiero]

I believe the KEEP process is rigorous and trustworthy. This proposal should go through it just like all others.

Some features like this would be nice in the language despite incompatible syntax. Some like my error-handling one (that I’m still working on but my full-time job eats a lot of my time) would be great. Their syntactic incompatibilities shouldn’t preclude them from consideration, just postpone them to 2.0 consideration.

I don’t think 2.0 should be for this, but I do think this might be for 2.0. Y’know?

[gildor]

But this is completely source incompatible, how can release this before 2.0?

[gildor]

I think you need at least a few good examples why so big syntax change would be useful and worth to add to plan for a future versions

[benleggiero]

I am trying to say this should be a major-version change. 2.0, 3.0, whatever.

[Pere Casafont]

by the way, in java an @Override for a method that implements an interface method is treated as an error: Override is not allowed when implementing an interface method

[gildor]

@Pere Casafont Actuay good point, but against this proposal, It was true for Java 5, but changed in Java 6, because allows to avoid some bugs with wrong override (implementation), also there is no annotation @Implement in Java

You also can check Override Javadoc:
https://docs.oracle.com/javase/8/docs/api/java/lang/Override.html

The method does override or implement a method declared in a supertype.

So, as you can see Java decided to use the same annotation for both cases

[Pere Casafont]

right haha