Generate rust bindings from Swift.

[simlay]

It looks like this project might be a little stagnant but I thought I'd show some interest and write some words on generating rust bindings from swift.

The front end of this (or one of the crates in here) should be both a library and an executable similar to cbindgen or rust-bindgen.

Some notes:

• cbindgen uses syn to parse the rust source to generate some of the C bindings.
• rust-bindgen uses clang-sys to get the AST of the C, C++ or Objective-C and then uses syn as part of the rust generation phase.

To move forward with this, I think we should try to follow similar choices in design. To parse the swift and parse the AST, we should use the swift tooling.

swiftc has some functionality to spit out the AST for a given file as shown here. After a bit of messing around, it would seem that we'd want to parse the swiftinterface. At least, that's what seems to be the closes thing to a header file.

I managed to get:xcrun swiftc -frontend -emit-syntax -target x86_64-apple-ios13.2-simulator -enable-objc-interop -enable-library-evolution -swift-version 5 -enforce-exclusivity=checked -Osize -module-name SwiftUI $(xcrun --show-sdk-path -sdk iphonesimulator)/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64.swiftinterface to produce a syntax tree. It doesn't like @objc syntax but I think there's a way to ignore that.

Anyway, the above spits out a lot of json. I'm not super into the idea of parsing that. We could look into getting some bindings to lib/Syntax using cmake-rs/bindgen or something.

[dvc94ch]

wondering what the advantage is over using rust-bindgen to bind to the c/objc apis. is it likely apple will build swift replacements and deprecate the c/objc apis?

[simlay]

wondering what the advantage is over using rust-bindgen to bind to the c/objc apis. is it likely apple will build swift replacements and deprecate the c/objc apis?

That's partly my fear. Each new version of iOS/macOS has more and more swift. Presumably in places where bugs can be fixed with swift, they use it.

SwiftUI for example is slowly closing the gaps for needing to touch UIKit. It still seems like SwiftUI just wraps UIKit with some nice defaults but I could see a world where they remove UIKit.