Open tfcporciuncula opened 1 year ago
Created a similar ticket in the KMMViewModel
project: https://github.com/rickclephas/KMM-ViewModel/issues/15
@tfcporciuncula this is an unfortunate side effect of the new code generation approach (with KSP). v1.0 generated extension properties/functions. Which in case of a generic class results in a generic function/property which isn't supported in Objective-C.
I am going to take a look at this to see if there is a way we can improve this 😄.
@tfcporciuncula Did you find a workaround? @rickclephas What do you recommend to tackle this issue?
Nope, I don't think there's a workaround. We didn't have a lot of cases where we were exposing flows, so we just minimized them even more and handled them ourselves without a library. You could also consider SKIE as I believe it doesn't have this limitation, but I haven't verified it myself.
@harry248 unfortunately there isn't really a proper solution. However there are some ways to workaround this limitation:
@NativeCoroutinesRefined
and refine the declaration in a Swift extension with a forced castand as @tfcporciuncula mentioned SKIE doesn't have this limitation since it doesn't use extensions.
I have a minimum reproducible example here: https://github.com/tfcporciuncula/native-coroutines-kotlin-18
Let's say we have something like this:
What I get from KMP-NativeCoroutines (Swift 5 Interface counterpart) is this:
The generic
T
becomesAny?
. I have a branch on Kotlin 1.7.20 and KMP-NativeCoroutines 0.13.1 so we can easily compare what we would get before, which is this:Here we can see
T
is there so we didn't lose anything. Is there anything I might be missing on my end or is that potentially a regression on the latest version?