Something I've been thinking about lately is that it might be interesting to start seriously considering Swift interop, or at the very least keep that possibility at the forefront with regard to any design decisions going forward.

Now that cxx-swift is starting to become usable, and I've managed to find a nice solution (which should be ready for testing next week) for distributing the Swift libraries on all the major platforms at build time, this means we should have access to basically the entire Swift compiler library tooling, not just ClangImporter.

Notably, one of the other Swift library components that looks quite interesting is PrintAsClang, which lets you dump a Swift module declaration as a clang header.

Theoretically, it seems like we should be able to use this functionality, along with the existing Objective-C to Rust translation semantics, to obtain a usable translation from pure Swift modules.

I haven't tried to use it at all yet so I don't know how well it works, but it's something to consider.

That also begs another question: if we have to rewrite a significant part of the header-translator in order to work with ClangImporter, would it maybe be a better idea to implement the new translation logic as a mapping from Swift to Rust (as much as possible anyway), rather than from Objective-C to Rust?

After all, ClangImporter is primarily meant to provide Swift modules, it just happens that (the way I understand how we would use it currently) we ignore that part and instead ask for the loaded Clang modules, so that we can iterate over those directly.

Reasons why it might be interesting to work with the Swift modules instead of the Clang modules:

• it would provide a way for us to implement Swift interop for pure Swift frameworks
• perhaps Swift is a cleaner target for mapping to Rust, and potentially already provides a lot of the semantic information (e.g., with regard to attributes, naming, derived declarations, etc.) we would have to reconstruct ourselves from the Clang modules
• this might be a better approach for working toward Improve Xcode support #459, since we also have access to the Swift compiler IDE support, which is what Xcode uses internally

Any thoughts on this?

One thing I was just thinking might be a downside to this is that most of the existing major frameworks are still implemented in Objective-C even when they have Swift interfaces. But I'm not sure this is really a problem because, at least for now (though extern "crabi" may change that), we would still have to link using the C FFI, so it's not like there would be a performance overhead in that regard. What we would gain would still be potentially cleaner and more universal translation semantics and the ability to leverage the other compiler libraries like the IDE support.