Hi, for using suspend functions in generic classes...

# touchlab-tools

[Jon Bailey]

Hi, for using suspend functions in generic classes I'm know we need to use the skie function like so: try await skie(A<NSString>()).foo() I think it would be nice if the Swift class (skie.A.__Kotlin) that wraps the generic ktolin class, wrapped everything not just the suspend functions. That way the skie function can be called once early in the code and that Swift class passed around instead of the Kotlin one. Skie could even generate Swift functions that wrapped any function that returns a A like so:

extension SomeFactory {
    func getA() -> skie.A.__Kotlin { skie(self.__getA()) }
}

[Filip Dolník]

Hi! These are interesting ideas however the problem is that we would have to generate a lot of Swift code which would significantly increase the compilation time (we are talking about 2x or something like that) and to some extend binary size. And the only benefit would be a slightly better syntax for this particular feature.

[Jon Bailey]

Would opt in only work? Maybe the way we use KMP is niche but we only have a few public factories that are called from Swift and those factories produce about 5 different types of generic classes.

I'll probably get used to it, but I keep forgetting that i have to call the skie function and then wonder why the function I'm looking for isn't there.

Otherwise maybe instead of hiding the suspend function for Objective-C, it could be marked as deprecated/unavailable and the message say to call the skie function?

[Filip Dolník]

The function has to be renamed because you may need to override it which wouldn’t be possible if it was unavailable. It cannot be deprecated because it would create a name conflict.

I’m not sure if we can generate a different unavailable/dummy function that would serve the same purpose because extensions for generic ObjC classes are somewhat limited and bugged - which is the reason we have to move the real function to another class. It would be possible to generate the function in Kotlin, but that would disable Kotlin caching / incremental compilation which would create a huge performance penalty.

As for having it as an opt in. Yeah, we could theoretically have it as an opt in, but implementing it would take us a lof of time.

The problem is that adding basically any feature to SKIE is much more difficult than might be obvious at first (and it continues to surprise even us). To give you an idea: It took us like 15 months to implement all the features that we today have in SKIE - with two full time developers.

So implementing this wrapping could easily take weeks or months and I don’t think that it would be used in practice because the performance cost is simply too high.