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

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

>> On Dec 11, 2015, at 9:03 AM, Geordie Jay <geojay at gmail.com <mailto:geojay at gmail.com>> wrote:
>> 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?
> It's mostly because that's how the parameter type validation logic I borrowed from @objc works, and I didn't have time to change it. The code for @cdecl has to be refined to support a "C-only" model, or maybe just only require ObjCInterop and 'import Foundation' when ObjC-specific constructs are used.

I’d like to have a look at making a simple C-only model of this. Compiler hacking is new to me though so I’ll be stabbing in the dark for a while. Can you elaborate as to whether you're referring to the block starting at line 4108 in 'lib/Sema/TypeCheckDecl.cpp’, or something else? Presumably there are already relevant type-checking routines for Swift's @convention_c functions, no?

>> In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:
>> http://romain.goyet.com/articles/running_swift_code_on_android/ <http://romain.goyet.com/articles/running_swift_code_on_android/>
>> Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?
> They're getting lucky. Swift function ABIs happen to coincide with C function ABIs in some cases, but this can't be relied on, and will probably break soon when we switch over the Swift-specific calling convention in LLVM.

Are we talking about safety / type checking? I mean about validating that we’re not asking for e.g. a Swift Struct in our @_cdecl function? Or is there something else at play? The goal of Swift is obviously to be safe, but since I’m so new to this, what I’d like to see first is something that ‘works' at all, and continue on the safe side after that. I’m just after a proof of concept for now.


I’m sorry about repeatedly starting new threads, I can’t figure out what the mailing list system expects of me. Even if I click reply from the web archive, which fills in the to/reply-to and subject (complete with RE: RE: etc.), it still starts a new thread. I haven’t felt this technically incompetent since the early 90s :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151211/99087524/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151211/99087524/attachment.sig>

More information about the swift-dev mailing list