Kotlin-native: Inline classes are not visible to Obj-C

[benasher44]

Minimal repro:

inline class Test(val str: String)

Assuming a file with that code is called test.kt (using konanc from the 1.2.1/1.3.31 release):

konanc -p framework test.kt -o test

This generates a framework, but the class Test is not in the header. If you were to add references to Test in another class, they would be exported as type id/Any.

[SvyatoslavScherbina]

Objective-C don't have a concept of inline classes.
How do you expect inline classes represented?

[benasher44]

I would expect a class that has the same methods/properties as the Kotlin version. I know the inline part doesn't map exactly, but I didn't expect this class to be unusable.

[benasher44]

This way, at least the Android consumers of the library/code could get the inline benefit. There's always going to be some overhead for the Obj-C and other interops.

[SvyatoslavScherbina]

Btw, iOS consumers using Kotlin can also properly consume inline classes.
On the other hand, Android consumers using Java also have some limitations, e.g. functions with inline classes in their signatures may not be available from Java.
So using inline classes is not perfectly compatible with interoperability.

[benasher44]

That’s a fair point. For those using inline classes, I think it makes sense that on the JVM side you primarily have the Kotlin consumers in mind, as the Java interop issues have mostly been decided/debated, whereas in native we have the opportunity to decide how this works. It seems like if it’s possible/reasonable, it’d be great to reduce pain in native, so that these classes are useable there and Kotlin consumers aren’t hindered

[SvyatoslavScherbina]

It is indeed possible.

[benasher44]

After further testing and discussion from #3032, I've found that an inline class that wraps a String in particular is exposed to Obj-C as id instead of NSString. It "works" for an inline class that wraps an Int though, which is exposed as an int32_t in Obj-C properties/methods.

This is still a bit weird to me. The nice thing about inline class is that you get the type safety of not being able to pass other inline class instances that happen to wrap the same type. When exporting to Obj-C/Swift, that type safety is erased.

[SvyatoslavScherbina]

Closing as duplicate of https://youtrack.jetbrains.com/issue/KT-32352