does anyone else think about Keep 87 as much as me...

# random

[d.medina]

does anyone else think about Keep 87 as much as me? https://github.com/Kotlin/KEEP/pull/87

[d.medina]

https://imgflip.com/i/48cv47

[Zach Klippenstein (he/him) [MOD]]

Omg yes. It's the only keep number I know by heart, and I've got a bunch of my teammates to remember it, and we talk about it all the time. Especially with our Swift counterparts.

[wasyl]

Latest comments on the issue are relatively old, is there any official statement regarding this feature? Is it likely to be implemented ever?

[darkmoon_uk]

As a newcomer to this issue; it doesn't have a clear use case up front. Without that it comes across as an esoteric feature which few will need or use, adding a maintenance burden and ultimately weakening the language. I'm personally troubled by talk of Dependency Injection - this is a pattern which IMO shouldn't be implemented at a language level. Dependencies are also the domain of Gradle. Maybe these terms are overloaded here, but at best this KEEP is poorly explained. At worst it's a dangerous lightning rod for fragmentation of the ecosystem. Heavy thumbs down 👎

[wasyl]

@darkmoon_uk This feature is not strictly about compile-time dependency injection (or any dependency injection). This is to allow declaring interfaces for foreign types, basically. So given e.g. class ExternalLibraryClass, I would be able to make it implement my own interface AppInterface, and then pass instance of the class whenever interface is expected. This is a very powerful feature, and something that can’t be properly done without language support

[darkmoon_uk]

@wasyl Oh ok, that sounds useful now; so a typical use case might be if I receive some precompiled API library, where one of the data types provided (lets say User) informally conforms to one of my own interfaces (Person), while formally it does not and cannot because it's a foreign type.
If I really need that conformance, architecturally, one common approach is a wrapper/proxy to add the interface conformance. But with this KEEP I could write a spec for the compiler to assert the behavioural conformance and treat User as a Person without wrapping?

[darkmoon_uk]

@wasyl They need to hire you as the front-man for the KEEP; much better explanation.

[wasyl]

I just hope my understanding is correct, but yes, your explanation is how I understand the benefits 🙂 But I’m afraid that’s where my understanding ends, and the KEEP is in much better hands 😉

[Zach Klippenstein (he/him) [MOD]]

Swift already has this feature (more or less). Another way to think about it (again, roughly, and probably with some different details), is that in swift, you can conform any (most?) types to any protocol, the type doesn't have to explicitly declare itself as confirming to the protocol where it's defined. There's a lot of really nice things you can do with this.

[Zach Klippenstein (he/him) [MOD]]

Eg in Java/kotlin, all types automatically get equals, hashcode, and toString methods, even if they don't make sense for that type. In swift, these concepts are all represented by separate protocols, and types have to opt-in to them. This is much more typesafe than just calling hashcode on a third party type and hoping the library authors remembered to implement it. Another use case is Comparable. If you can, in your own code, make any type "implement" Comparable, you don't really need the concept of a Comparator. You could take any third-party library type and just provide an implementation of Comparable for it.