Once again, it's been a while since the last updat...

# swift-export

[sergey.bogolepov]

Once again, it's been a while since the last update. Let me share with you what we accomplished in September and October. It's Friday evening, so I'm going to be brief 🙃

Open and Abstract Classes. We have finally completed all the necessary parts, and now the Liskov substitution principle is working at the interop border. Yay!
Nullability. T? in Kotlin becomes T? in Swift. Interestingly, even in this relatively "obvious" case, there was a tricky issue around translating Nothing? to Never? :)
List, Map, Set. We decided not to reinvent the wheel here. Under the hood, the Swift export reuses existing nice Objective-C export machinery. Thanks to Objective-C - Swift interop, these NS* collections are bridged to the corresponding Swift collections.
@Deprecated. As I mentioned in the last post, this was a tricky topic due to multiple differences between @Deprecated and @available, but it seems we found and implemented a more or less consistent solution.

What's next?
Enums and Sealed Classes. As with many other features, we are starting with the most straightforward solution. Enums and sealed classes will be translated to Swift classes instead of enums, providing a user experience similar to vanilla Objective-C export, which is somewhat "meh". However, it is important for us to lay down a foundation that we can use to make Swift export more Swift-like in the future.
Extensions. We are taking a conservative approach here as well, initially exporting the extension receiver as the first parameter of a function (similar to how Kotlin extensions are exported to Java).
Why? Consider the following example Kotlin code:

class A
class B : A()

fun A.foo() = print("a")
fun B.foo() = print("b")

val a: A = B()
a.foo() // Outputs: "a" because of static dispatch

In Swift, one cannot override extensions without @objc override, and using it to "fix" will lead to dynamic dispatch and the output "b" instead of "a".
Overrides. The Kotlin type system is much more flexible when it comes to property and method overrides. It will take us some time to find workarounds for all reasonable corner cases 🙃
Interfaces. Our next big milestone is to support the export of Kotlin interfaces as Swift protocols. Implementing a full solution (e.g., allowing a random Swift struct to implement a random Kotlin interface and be passed to a Kotlin function) is highly challenging, but we will take a step-by-step approach to tackle it.

[Anonymike]

Thank you Sergey for the honest update once again. I really appreciate this insight and look forward to exploring this functionality when it gets there. The objective c side of multiplatform is the biggest thing holding as back from doing deeper work with some of the apple side only because it is so much more troublesome to debug, understand, and we are constantly bridging those parts of our code back to swift with quirky issues between swift and objective c compatibility. Going direct to Swift is a huge win for us.

All this is to say we appreciate your hard work. If there's any way we can support the progress let please feel free to reach out.