<@U092308M7> so I wanted to see a KEEP because 1) ...

# multiplatform

[eddie]

@orangy so I wanted to see a KEEP because 1) it seemed that would be the way changes (especially ones as significant as this) would be introduced to Kotlin going forward and 2) so far I hear that you need two modifiers for some reason, but no one is able to explain why much beyond "well it helps in the IDE", and that's just not a valid reason to bloat a language IMO.

[Ruckus]

I'd just like to point out (again) that "it helps the IDE" is incredibly important in a language like Kotlin where the tooling is as much a part of the language experience as the code itself. I'm not saying it's the only reason, but don't dismiss it as insignificant.

[abreslav]

+1 The IDE is really important

So far we’ve been keeping it safe and required a handshake between expecting/actual code wo make sure no changes can mess things up without the user noticing. This is much analogous to why we require the override modifier

[eddie]

@Ruckus @abreslav I don't mean to dismiss it; I really enjoy the integration with IntelliJ. However, I'd argue that you can remove the keyword on the implementation side while retaining the help the IDE would provide (like a special syntax highlighting variation or something in the gutter, for instance). This way the IDE could provide help in the same way that it provides Inspections and Intentions: not everyone needs or wants all of those turned on, so they're configurable. If you require a keyword in the language you lose that flexibility.

[eddie]

IntelliJ's newer parameter hints feature is another example of this done well, IMO.

[abreslav]

It’s more about what can and c=not be done fast in the IDE. Some things can’t be computed quickly if they are not in the code

[eddie]

But you already have to mark the module in your gradle build script as one that provides implementations, no? At the end of the day, I just need to know if an expected implementation is available or not.