from_swift.png

# kotlin-native

[yuya_horita]

from_swift.png

[olonho]

unfortunately, most generics (but for collections) from Kotlin are erased before presenting to Objective-C/Swift

[yuya_horita]

Will it be modified in the near future?

[yuya_horita]

maybe, improved is better expression than modified

[olonho]

It could be, but not immediately

[yuya_horita]

sounds good. Thank you.

[yuya_horita]

Could you show me a simple example above most generics (but for collections) from Kotlin are erased ?

I tried, but generic type becomes Any even for Collection.
maybe, I might have misunderstood.

[yuya_horita]

Thank you 🙏

[kpgalligan]

@olonho I’m digging into this now. Hand-modifying the generated objc header seems to work fine with generics, so is this just that generics weren’t a priority, or are there significant technical issues?

[svyatoslav.scherbina]

There are some technical issues. For example, Objective-C doesn't have genetics in protocols. Generics in classes are slightly different in Kotlin and Objective-C (e.g. around nullability). Also emitting generics would require some refactoring.
The priority depends on demand too. Would generics support for classes only be useful for you?

[kpgalligan]

My current focus is largely on making KN more appealing to Swift developers. There are a number of things I’m looking at, but adding generics to the objc output would seem like a relatively easy win, depending on the conditions you mentioned. Obviously not perfect, but something to consider.

[kpgalligan]

I’m going to poke around a bit more to see other discussions about future plans and swift, but any info would be really useful.

[kpgalligan]

The next “big issue” is structs and value types, which has a far less clear solution, but one thing at a time

[svyatoslav.scherbina]

Another major issue with generics is variance.
Objective-C doesn’t have use-site variance (e.g. val x: Class<out T>), it only has declaration-site variance (class Class<out T>). Swift ignores even the latter and doesn’t support variance at all.

[kpgalligan]

Thanks for the info! I’ll be digging into this as deeply as possible over the next few weeks, so any info is very useful. Any other thoughts on interop through objc headers, and possibly any insight into future interop changes with Swift? I assume that’s not really on the radar, but any info is very useful.

[svyatoslav.scherbina]

and possibly any insight into future interop changes with Swift?

Direct interop with Swift is expected to be hard to implement. Swift and Kotlin are quite different languages, and Swift doesn’t seem to have as flexible runtime as Objective-C has.

[kpgalligan]

Really appreciate the info. Doing a 4-way deep dive on generics (Java, Kotlin, Objc, Swift) to get my head around issues. The demand question has to do with how iOS teams would view Kotlin interop. For Swift-leaning teams, the experience so far is “this is more Objective-C” rather than “this is Kotlin”. Technical issues aside, that is an area of political pushback. Many iOS projects are still largely Objc, and in those situations, this isn’t so much an issue. For teams that go heavy on Swift, there’s a strong effort to isolate the parts of code that need to talk to Objc, and a reluctance to add “more Objc”. The translation from Kotlin to Objc will inevitably lose some info, so the goal is to see if we can preserve some more of that. We’re also exploring some code gen to help create a more “Swift-like” api. That’s far more speculative, and may go nowhere, but early days.

[kpgalligan]

@svyatoslav.scherbina I’ve been putting some time into this and have an early POC working fairly well (https://github.com/kpgalligan/kotlin-native/tree/kpgalligan/20190315/generics). There are restrictions and complications for sure, but generics also add some clarity on the consuming end. However, getting a feature change like that into the core platform is obviously a pretty big undertaking, and there may not be interest from all sides. Rather than simply maintaining a fork of K/N for the near future, what about making the header generation something that’s pluggable? Sort of an experimental flag. That feels kind of ugly, but the compiler plugin system isn’t “official” yet, so short of maintaining a fork I think it’ll be really difficult to push changes back into the platform on something core like this. We’ve made some explicit compromises on nullability, variance, etc. Will post some kind of design doc to start a discussion. Not sure of the best venue for that, though.

[svyatoslav.scherbina]

Thank you for the work done!

Rather than simply maintaining a fork of K/N for the near future, what about making the header generation something that’s pluggable?

I don’t consider Objective-C interface generation mature enough to make it pluggable. It may be found easy to add single extension point to post-process the entire header AST, but this would definitely make supporting generics much harder.
Also most of other generated header adjustments I could imagine would require also some customization of code generation, which is even more immature and internal.

So besides maintaining a fork of K/N I can’t find any other solution than to getting this feature into the core platform.