<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 11:41 AM, Geordie Jay <<a href="mailto:geojay@gmail.com" class="">geojay@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 9:03 AM, Geordie Jay <<a href="mailto:geojay@gmail.com" class="">geojay@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span id="mailbox-conversation" class=""><div class=""><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Hi Joe,</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">I was just commenting on your @_cdecl commit on GitHub but I’ll keep the discussion here.</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; min-height: 17px; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">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?</div></div></span></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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?</div></div></div></div></blockquote><div><br class=""></div><div>The checking code is in the "isRepresentableInObjC" family of functions around there, yeah. @convention(c) didn't need to distinguish C from ObjC on Darwin platforms, since ObjC and Foundation are always available there, so we didn't bother trying to separate them. You could probably get started by just disabling the checks for Foundation and ObjC interop altogether and avoiding touching any class, block, or CF types (which probably is easy on Android).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span id="mailbox-conversation" class=""><div class=""><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class=""><a href="http://romain.goyet.com/articles/running_swift_code_on_android/" class="">http://romain.goyet.com/articles/running_swift_code_on_android/</a></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; min-height: 17px; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?</div></div></span></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><br class=""></div><div>I'm talking about linkage safety. If swiftc exports a swift function with a certain symbol name, and C code links against it, we don't want to guarantee they'll use the same calling convention, unless the function is explicitly exported with an attribute saying it uses the C calling convention.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>