When swift export is "ready" will it help with pro...

# swift-export

[Pearce Keesling]

When swift export is "ready" will it help with problems around using primitives in generics? Right now (not using swift export) if I try to use something like String as a generic it won't work because String is not a class, I end up having to use NSString and do some converting. Is this a fundamental limitation or something that swift export will solve?

[Artem Olkov]

Hello there 🙂 The feature you are asking about should already be working on 2.4.0-Beta2 with swift export 🙂

[Pearce Keesling]

That is amazing! I'll see if I can get our app working with swift export! I got very stuck trying with Beta1 but maybe Beta2 will work 🤞

[Artem Olkov]

It's OK to ask for help in this channel, I try to provide as much support as I can 🙂 Sometimes that results in us discovering a bug, but that's a good thing 🙂

[Sam Rayner]

You do a fantastic job Artem

[Pearce Keesling]

Are there currently known limitations with generics in swift-export? I'm noticing that some of the generics are being generalized to their upper bound which matches the current docs, but I assume those are a reflection of 2.3 not 2.4

• When exported to Swift, Kotlin generic type parameters are type-erased to their upper bounds.

What's interesting is it might just be nested generics, but I need to dig a little deeper through the generated kotlin code

[Pearce Keesling]

Actually it is happening in the constructor for a data class:

// Kotlin code
data class ManualAccountFormBinding(
  val name: FormBinding<String>,
  val typeId: FormBinding<String>,
  val openingBalance: FormBinding<Double>,
  val statementDate: FormBinding<String>,
)
//Generated kotlin code
@ExportedBridge("com_quicken_accountDiscovery_ManualAccountFormBinding_init_initialize__TypesOfArguments__Swift_UnsafeMutableRawPointer_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding__")
public fun com_quicken_accountDiscovery_ManualAccountFormBinding_init_initialize__TypesOfArguments__Swift_UnsafeMutableRawPointer_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding_ExportedKotlinPackages_com_quicken_form_FormBinding__(__kt: kotlin.native.internal.NativePtr, name: kotlin.native.internal.NativePtr, typeId: kotlin.native.internal.NativePtr, openingBalance: kotlin.native.internal.NativePtr, statementDate: kotlin.native.internal.NativePtr): Boolean {
    val ____kt = kotlin.native.internal.ref.dereferenceExternalRCRef(__kt)!!
    val __name = kotlin.native.internal.ref.dereferenceExternalRCRef(name) as com.quicken.form.FormBinding<kotlin.Any>
    val __typeId = kotlin.native.internal.ref.dereferenceExternalRCRef(typeId) as com.quicken.form.FormBinding<kotlin.Any>
    val __openingBalance = kotlin.native.internal.ref.dereferenceExternalRCRef(openingBalance) as com.quicken.form.FormBinding<kotlin.Any>
    val __statementDate = kotlin.native.internal.ref.dereferenceExternalRCRef(statementDate) as com.quicken.form.FormBinding<kotlin.Any>
    val _result = run { kotlin.native.internal.initInstance(____kt, com.quicken.accountDiscovery.ManualAccountFormBinding(__name, __typeId, __openingBalance, __statementDate)) }
    return run { _result; true }
}

and then it fails with an error because it is trying to pass FormBinding<Any> into FormBinding<String>

Showing Recent Messages
e: file:///[...]/build/SwiftExport/iosSimulatorArm64/Debug/files/ComQuickenSharedAccountDiscoveryApi/ComQuickenSharedAccountDiscoveryApi.kt:2924:123 Argument type mismatch: actual type is 'FormBinding<Any>', but 'FormBinding<String>' was expected.

[Pearce Keesling]

Managed to work around that one by hiding the constructors for the data class, but now I think I'm stuck on a coroutines issue:

Showing Recent Messages
org.jetbrains.kotlin.backend.common.CompilationException: Back-end: Please report this problem <https://kotl.in/issue>

/Users/pkeesling/Documents/GitHub/app-components/packages/mobile/sharedKt/swiftUmbrella/build/SwiftExport/iosSimulatorArm64/Debug/KotlinCoroutineSupport/KotlinCoroutineSupport/KotlinCoroutineSupport.kt:-1:-1

Details: Internal error in file lowering: java.lang.IllegalStateException: Internal compiler error: doesn't correspond to any C type: kotlin.native.internal.NativePtr

at /Users/pkeesling/Documents/GitHub/app-components/packages/mobile/sharedKt/swiftUmbrella/build/SwiftExport/iosSimulatorArm64/Debug/KotlinCoroutineSupport/KotlinCoroutineSupport/KotlinCoroutineSupport.kt (240:115)

GET_VAR 'continuation: kotlin.native.internal.NativePtr declared in <root>.SwiftFlowIterator_next' type=kotlin.native.internal.NativePtr origin=null

[Artem Olkov]

Are there currently known limitations with generics in swift-export?

Yes, generics currently are type erased to the upper bound 🙂 The full support for the generics are currently in development, we are not sure how much time it will take, but we are working on it.

but now I think I'm stuck on a coroutines issue:

Well, that's new. Do you have a reproducer for that to share? What versions of kotlin, kotlinx-coroutines and swift are you using?

I feel like I've seen something like that couple moth ago, but it should be already fixed in 2.4.0-Beta2.

and then it fails with an error because it is trying to pass FormBinding<Any> into FormBinding<String>

Reproduced with

class FormBinding<T>(val bind: T)

data class ManualAccountFormBinding(
    val name: FormBinding<String>
)

Thanks for the report, we will try and fix that (sadly not in 2.4.0) 🙂
KT-85981 [Swift Export] generic property with specified type generates uncompilable bridges

[Pearce Keesling]

Thanks for looking into it! I'll see if I can find a reproducer, I think we were on the latest release of coroutines, I'll check on that. I might be able to try and do a minimal repro, but I'm not really sure where to start since that code doesn't really correspond to any of my code like the first issue did where I could find the offending data class

[Artem Olkov]

any special handling for the coroutines library in the gradle? Do you have some feature flags past to the compiler? Do you have anything special in gradle properties?

[Pearce Keesling]

It looks like I was on the latest rc 1.11.0-rc01 so that might be a part of it