Kotlin-native: Compiler should not try to produce typealias actual declarations as public API

[damianw]

If I have in a common module:

expect class Decimal
data class Foo(val value: Decimal)

and in an iOS module:

@Suppress("CONFLICTING_OVERLOADS") // perhaps would not be needed if this problem was solved?
actual typealias Decimal = NSDecimalNumber

I wouldn't expect that the compiler would also try to export NSDecimalNumber as a public API; Foo should be accessible from the native module with an argument of type NSDecimalNumber. Currently the compiler throws an error: can't produce platform.Foundation.NSDecimalNumber to framework API

[SvyatoslavScherbina]

Foo should be accessible from the native module with an argument of type NSDecimalNumber

And this is exactly the case that is not supported yet: generating API with imported Objective-C types in its signatures.

If you need to construct Decimal and access NSDecimalNumber only from Kotlin code, you can do something like this as a workaround:

actual data class Decimal internal constructor(internal val nsDecimalNumber: NSDecimalNumber)

[damianw]

Apologies if this limitation is already being tracked. I could not find it in the tracker.

[SvyatoslavScherbina]

This limitation is not being tracked yet, so there is nothing to apologize for.

[SvyatoslavScherbina]

We have added some preliminary support for the case discussed above. It is available starting from 0.7-dev-1493
Only some early steps are done, so this support can be a bit buggy.

[damianw]

@SvyatoslavScherbina Thanks! I have tinkered with the latest changes and found a bug or two as you mentioned. Would it be helpful at this stage to publish an example and create an issue? Or perhaps just post it in the thread for this issue?

[damianw]

For what it's worth, I have documented the problem here: https://github.com/damianw/KonanReturnValueAndSelectorBug

[SvyatoslavScherbina]

@damianw thank you for the perfect report! We've found the root cause of the crash. It is our incorrect assumption that any NSNumber instance is a box for a primitive-typed value. However, NSDecimalNumber is not.
So NSDecimalNumber doesn't work in Kotlin code currently. I'll take a look to check whether it is possible to fix this fast.

[damianw]

Thanks for the quick turnaround on this issue!

[SvyatoslavScherbina]

We've merged the fix to master branch. Please feel free to report any other bugs.

[olonho]

Closing as issue seems to be fixed, please reopen if anything else to be done.