<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Indeed I was - I'm quite sorry for the confusion, I didn't make my intent clear as I should have, such as through example. What I'm referring to is, for instance, offering a way for a Ruby library to interface with a module written in Swift to communicate with Redis (as an example, not something I'm thinking too seriously about).<br><br>Sent from my iPhone</div><div><br>On 23 Dec 2015, at 19:20, Jason Dusek <<a href="mailto:jason.dusek@gmail.com">jason.dusek@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I think the OP was asking not about importing C symbols into Swift but rather exporting Swift to C.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, 23 Dec 2015 at 15:18 Brent Royal-Gordon via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What are the current facilities planned or in development for FFI? Just as Swift functions can be exposed through @objc, how would I add a similar capability for pure C? Is this what, in fact, module maps might be for?<br>
><br>
> I ask since writing high performance native code for dynamic languages is currently done in C, and that’s a pretty bad idea. It would be great for Swift if people started writing native bindings in it as opposed to C, but it probably needs at the least a way to re-export global public functions for C/C++.<br>
><br>
> Please let me know if I should take this to swift-dev or swift-evolution!<br>
<br>
Swift does not require a foreign function interface—it can directly call C functions. Sometimes Swift generates a trampoline to do this, but often not even that. The module map basically just tells Swift which headers and binaries make up a particular module. There's generally no need to write any bridging code—it just works.<br>
<br>
There are a few C constructs that Swift doesn't support very well, like unions and fixed-size arrays in structs. In those cases, you may need to write some C functions which perform the operations that can't be easily expressed in Swift, but these functions would just be plain old C with no special bridging involved. Similarly, you may choose to write wrappers around some of your library's C constructs to make them more convenient to use—for instance, if your library has a struct called `foo` and an operation on that struct called `frobnicate_foo()`, you might extend `foo` to add a `frobnicate()` method to it. But this is purely optional, and you would write it in plain old Swift.<br>
<br>
Though Apple's platforms are most commonly associated with Objective-C, there's a lot of C over there too. Swift works very well with it—this stuff is fast, as transparent as it can be, and frequently exercised.<br>
<br>
In short: Just try it. It's pretty easy.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
</blockquote></div>
</div></blockquote></body></html>