<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 11, 2016 at 11:47 AM Joe Groff <<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Apr 11, 2016, at 11:36 AM, Daniel Farina via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
><br>
> I've been playing with recent versions of Swift on Linux and think the whole thing is rather neat. I'm most curious about how swift programs might be embeddable in C projects.<br>
><br>
> I found a number of documentation artifacts about calling C functions and providing Swift callbacks to C, but none about how to disable mangling of symbols or doing whatever else was necessary to allow C programs to link a Swift .o/.so.<br>
><br>
> Also ambiguous to me are runtime requirements, particularly in terms of background threads and memory management. Many of the target C programs I have their in mind have their own memory and concurrency management strategies, e.g. extensions for Python, Ruby, Postgres...<br>
><br>
> Is this something that works? Or could be made to work? Has a lot of subtle problems besides throwing "convention(c)" on some functions and turning off mangling?<br>
><br>
> Thanks for considering my questions.<br>
<br>
Swift uses its own calling convention for Swift-to-Swift calls, so it's not a simple case of disabling mangling. We don't have a supported solution yet for exporting symbols with C linkage and calling conventions, but in master there is a prototype of an attribute, @_cdecl("foo"), which can be used on a function to export it as a C-callable function named foo. For instance:<br>
<br>
@_cdecl("module_foo")<br>
func foo(x: Int) -> Int { return x + 1 }<br>
<br>
would be usable from C or ObjC as:<br>
<br>
int module_foo(int x);<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>Very cool. The reference to "_cdecl" will help me out with searching the source, too.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that you still can't define C-compatible struct types from within Swift; they must be defined in C and imported into Swift. Regarding runtime requirements, Swift requires its runtime to function, and there's a requirement that any Swift code that interacts must share the same runtime within a process. Since Swift is not yet ABI-stable, if your primary intent is to provide a shared library for use from C, you may want to statically link the Swift standard library into your .so, and only export C symbols from it for external use. That should keep the "Swiftiness" of the shared library as an internal implementation detail.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Yes, that's exactly the goal. One follow-up question: I'm not so much concerned about there existing some runtime, but rather what is in it. In particular, threads, memory management that is hard to integrate with other programs, or something else that you might think an impediment to embedding in other programs that have concurrency or memory models.</div><div><br></div><div>Thanks for your help.</div></div></div></div>