<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 Nov 28, 2016, at 7:26 AM, Brian Gesiak via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello all!<div class=""><br class=""></div><div class="">While reviewing <a href="https://github.com/apple/swift/pull/5904" class="">https://github.com/apple/swift/pull/5904</a>, I had a crazy thought, and I'd like to get some feedback on it.</div><div class=""><br class=""></div><div class="">Here's my original comment <<a href="https://github.com/apple/swift/pull/5904#discussion_r89797900" class="">https://github.com/apple/swift/pull/5904#discussion_r89797900</a>>.</div><div class=""><br class=""></div><div class="">Basically, I notice that we have two sets of targets we compile the Swift runtime and standard library for:</div><div class=""><br class=""></div><div class="">1. 'ALL_APPLE_PLATFORMS', which is composed of macOS, iOS, tvOS, and watchOS.</div><div class="">2. The other platforms: Linux, FreeBSD, Android, Cygwin, and (as of the pull request above) Windows.</div><div class=""><br class=""></div><div class="">In other words:</div><div class=""><br class=""></div><div class="">1. All the platforms that support Objective-C interop. I suggest we call these 'OBJC_INTEROP_PLATFORMS' in CMake.</div><div class="">2. All the platforms that don't. I suggest we call these 'NO_OBJC_INTEROP_PLATFORMS' in CMake.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">I think the above is a good idea, regardless of how you feel about my other, zanier thought:</div><div class=""><br class=""></div><div class="">Over the weekend I learned of the mulle-objc project <<a href="https://mulle-objc.github.io" class="">https://mulle-objc.github.io</a>>. It boasts an Objective-C compiler and runtime that works on Linux.</div><div class=""><br class=""></div><div class="">Now, I don't know if Swift's Objective-C interop will work completely with mulle-objc, but I did a bit of experimenting over the weekend, and it seems possible. But one obstacle is the fact that the Swift build system conflates "an Apple target" with "capable of Objective-C interop." To even start working with mulle-objc, I had to remove a lot of `#ifdef __APPLE__` in the code.</div></div></div></blockquote><div><br class=""></div><div>Yeah. I’d expect the main work to be in the Swift build system, the Swift driver (which decides when to pass down “-enable-objc-interop” to the frontend), and some “#ifdef __APPLE__” in the runtime that should use “#if SWIFT_OBJC_INTEROP” instead.</div><div><br class=""></div><div>Swift does bake in a bit of knowledge of the Darwin Objective-C runtime, so one would likely have to tease that out of IRGen and the runtime to make mulle-objc interoperability possible. Clang has some abstractions in its CodeGen (equivalent to Swift’s IRGen) to support multiple Objective-C runtimes, and we would need something similar for Swift. That’d take a bunch of refactoring.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">So I'd like to propose that we augment the build system to allow a person compiling the Swift project to turn Objective-C interop on or off for any given target. That would allow me to compile for Linux, but with Objective-C interop enabled. Alternatively, I could compile for macOS, but with Objective-C interop disabled.</div><div class=""><br class=""></div><div class="">Any thoughts? I could clean up my local implementation and send a pull request, provided there's interest.</div></div></div></blockquote><br class=""></div><div>It would be great to decouple “is an Apple platform” from “provides Objective-C interoperability”!</div><div><br class=""></div><div>As you noted, there are two potential use cases for this:</div><div><br class=""></div><div>1) Objective-C interoperability on non-Apple platforms: I (personally) don’t find this hugely motivating, because Apple platforms have the only significant stack of existing frameworks that Swift needs to interoperate with. Plus, there’s no single clear “winner” when it comes to picking an Objective-C runtime on non-Darwin platforms (e.g., what about GNUstep?), and (as I said above) actually supporting another Objective-C runtime is likely to require a bunch of refactoring in IRGen and runtime.</div><div>2) Swift-without-Objective-C interoperability on Apple platforms: this would be *extremely* useful for people writing cross-platform code in Swift, who want to make sure their code works the same way when using Darwin’s Foundation vs. the core libraries’ Foundation. I know that the Foundation developers would be particularly pleased with this.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>