[swift-dev] Proof-of-concept port of Swift for Android

Geordie Jay geojay at gmail.com
Fri Dec 11 11:03:13 CST 2015

Hi Joe,

I was just commenting on your @_cdecl commit on GitHub but I’ll keep the discussion here.

I was wondering what it is about your implementation that makes it rely on ObjC interop, as you noted. And whether this dependency can be removed for a quick and dirty proof of concept, or whether it’s something more fundamental than that?

In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:


Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?

Best regards,


(Joe: apologies for the double up, I’m evidently terrible at mailing lists and hit reply instead of reply all!)

On Fri, Dec 11, 2015 at 5:53 PM, Joe Groff <jgroff at apple.com> wrote:

>> On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev <swift-dev at swift.org> wrote:
>>> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev <swift-dev at swift.org> wrote:
>>> Hi, maybe one of the Apple devs can help out with this quick Q:
>>> To interface with the JNI, we’d presumably need to call swift functions from our compiled swift binaries from C (or directly from Java, the result being the same). Is there a way to demangle certain symbols in the output binary to this effect, or is there another / a better way to access Swift functions from C?
>> Others can probably give a more detailed response, but...
>> There’s a Swift demangler in Swift’s “Basic” library (lib/Basic/Demangle.cpp), along with a standalone tool (swift-demangle) you can experiment with. The information in the mangled name should be complete enough to call, but you’ll need to match Swift’s calling convention.
>> If it’s just a specific set of Swift functions you want to call from C, you can use the @_silgen_name attribute to override the mangled name, and/or make them @convention(c) to use the C calling convention.
> @_silgen_name isn't the right answer here, since the convention will be wrong, and it won't interact properly with Clang imports and exports. Like Slava said, you want something like the '@_cdecl' attribute he proposed and I half-implemented.
> -Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151211/4112c5fb/attachment.html>

More information about the swift-dev mailing list