Add support for Swift

[tomleavy]

My team is interested in adding Swift bindings to diplomat. Our current Rust library will have C++, JS, Swift, and Java bindings that need to be created. We have successfully experimented with Swift and Java by manually creating some basic bindings to prove out the use case and would like to automate.

• One thing thing that I do not see within diplomat that we would eventually require is the ability to generate bindings for async methods.

• There are callbacks that our library has passed into it, and it is my understanding calling back to other languages is out of scope, but is there an ability to inject custom logic into the code generation so we could accomplish that on a case by case basis with existing tools for calling other languages from Rust?

[Manishearth]

• and it is my understanding calling back to other languages is out of scope

This is incorrect: calling back into other languages is in scope, but on our terms only.

As in, if the callback API can be defined on the Rust side with diplomat-friendly types, that is in scope.

What is not in scope is being able to bind to arbitrary APIs on the other side since it's impossible to talk about that uniformly across languages.

Callback support is something we want, it mostly just needs to be implemented. I filed a separate issue about this: #146

One thing thing that I do not see within diplomat that we would eventually require is the ability to generate bindings for async methods.

I've thought about this a bit but it seemed tricky to come up with a design that would work in a cross-language fashion. I'm not opposed to async support in Diplomat, it's just that async in so many languages is highly tied to that language's runtime and it's hard to uniformly deal with, so we'd probably need some design work first.

[tomleavy]

This is incorrect: calling back into other languages is in scope, but on our terms only.

As in, if the callback API can be defined on the Rust side with diplomat-friendly types, that is in scope.

That makes sense, I was hoping that is the case.

I've thought about this a bit but it seemed tricky to come up with a design that would work in a cross-language fashion. I'm not opposed to async support in Diplomat, it's just that async in so many languages is highly tied to that language's runtime and it's hard to uniformly deal with, so we'd probably need some design work first.

Each language will definitely require different code generation to properly handle the "callback" portion. I did a project where we needed this functionality and we first got FFI generation to the format below and then integrated the C version into swift without issues. For Javascript you would need a bridge to Promises from the js_sys crate, for Java you would need JNI code generation for calling Runnable objects etc.

async fn foo(bar: u32) -> u32

void foo(uint32_t bar, void(*on_complete)(uint32_t))

[Manishearth]

Yep! And designing that such that it can be handled uniformly is tricky, but doable.