Gotcha that makes sense <@U0B8UEMV1> thanks for th...

# arrow

[Robert Menke]

Gotcha that makes sense @pakoito thanks for the explanation. 🤞 for KEEP87 😉.

[raulraja]

We are getting the features of KEEP-87 regardless via compiler plugins so we will get type classes even if the proposal does not make it 😀

[raulraja]

https://github.com/47deg/arrow-meta-prototype/blob/rr-typeclasses-plugin/compiler-plugin/src/main/kotlin/arrow/meta/typeclasses/TypeClassesPlugin.kt

[raulraja]

Still in development

[Robert Menke]

Great 🙂 very exciting to hear

[thanh]

Wow, it's very cool. And a curious question from me: are there some things that keeps JetBrain against Keep87? Raul?

[kioba]

on the Android Developers Backstage podcast the latest episode is with Andrey Breslav. He said with the next version of Kotlin (1.4) they are focusing on rewriting the compiler backend and frontend and they try to add less feature to the language. It was a great interview listen to it if you got time 🙂
source: http://androidbackstage.blogspot.com/2019/08/episode-119-kotlin-with-andrey-breslav.html

Andrey also mentioned that he would like to see Type Classes (aka Compile-time Extension Interfaces 😅) in the language. He said that on the closing panel session at KotlinConf 2018 but it might not be in the current suggested form. Probably he might want to see some inspiration form other languages and how they work. maybe somethign like the rust way 🤷‍♂️ .

https://youtu.be/heqjfkS4z2I?t=2572▾

[raulraja]

@thanh I don't think Jetbrains is against KEEP-87. As Karoly mentioned they are trying to figure out what the lang needs without bloating it with features. What I can say though is that type class compilation is fast in Kotlin because we don't have scoped implicits and we can resolve the factories just looking at the data type package or type class package to resolve injections

[raulraja]

This is trivial compared to a lot of the work the compiler already does