Open simlay opened 4 years ago
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?
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.
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
orrust-bindgen
.Some notes:
cbindgen
usessyn
to parse the rust source to generate some of the C bindings.rust-bindgen
usesclang-sys
to get the AST of the C, C++ or Objective-C and then usessyn
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.