Is there an issue for default types for generic ty...

# language-evolution

[Edoardo Luppi]

Is there an issue for default types for generic type parameters? And, has this ever been considered as a language enhancement?

[Sam]

I've seen a few, but I think this one is the most recent and most discussed: https://youtrack.jetbrains.com/issue/KT-52519

[Edoardo Luppi]

Thanks! Honestly, I'd love to see this kinda stuff much more than collection literals 😭

[mikhail.zarechenskiy]

What is your use-case?

[Edoardo Luppi]

Improvement in UX. I use TypeScript as much as I use Kotlin, and working with types that use default generics is much more pleasant than having to write the same type every time.
There are situations where you offer a generic type parameter, but you expect a specific type to be used the most. Expressing that as a default is much cleaner imo.
Rust does that too to some extent if I'm not mistaken.

[Edoardo Luppi]

The current approach to provide "default" generic types is to extend the type hierarchy. It's all boilerplate that could be avoided.

[mikhail.zarechenskiy]

In case of types, typealias can be used as well

[Edoardo Luppi]

But that's just masking the problem imo. Another interesting case is trying to reproduce external TS types under K/JS or K/WASM.
I haven't found a proper approach for APIs that use default generic types extensively. It takes one default type to propagate so much unnecessary code all over Kotlin externals.

[mikhail.zarechenskiy]

Interop with TS is a clear case, yes, but a quite separate one

[Edoardo Luppi]

Would you consider it separate in the sense you'd be up to think about a solution for interop, but not for the language in general?

[mikhail.zarechenskiy]

Right. As usual, it all depends on use cases we want to cover. If interop is the main goal, I believe we can come up with a simpler solution without introducing a new feature to Kotlin

[Edoardo Luppi]

Understandable!
I still think it could provide value to the language tho. Kotlin took the nice approach of being concise and clean, which also means less mental overhead. Less code and types to write (be it subclasses or typealiases), reduced API surface, reduced complexity.