> On Nov 28, 2016, at 7:26 AM, Brian Gesiak via swift-dev <swift-dev@swift.org>
> wrote:
>
> Hello all!
>
> While reviewing https://github.com/apple/swift/pull/5904
> <https://github.com/apple/swift/pull/5904>, I had a crazy thought, and I'd
> like to get some feedback on it.
>
> Here's my original comment
> <https://github.com/apple/swift/pull/5904#discussion_r89797900
> <https://github.com/apple/swift/pull/5904#discussion_r89797900>>.
>
> Basically, I notice that we have two sets of targets we compile the Swift
> runtime and standard library for:
>
> 1. 'ALL_APPLE_PLATFORMS', which is composed of macOS, iOS, tvOS, and watchOS.
> 2. The other platforms: Linux, FreeBSD, Android, Cygwin, and (as of the pull
> request above) Windows.
>
> In other words:
>
> 1. All the platforms that support Objective-C interop. I suggest we call
> these 'OBJC_INTEROP_PLATFORMS' in CMake.
> 2. All the platforms that don't. I suggest we call these
> 'NO_OBJC_INTEROP_PLATFORMS' in CMake.
>
> ---
>
> I think the above is a good idea, regardless of how you feel about my other,
> zanier thought:
>
> Over the weekend I learned of the mulle-objc project
> <https://mulle-objc.github.io <https://mulle-objc.github.io/>>. It boasts an
> Objective-C compiler and runtime that works on Linux.
>
> 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.
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.
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.
> 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.
>
> Any thoughts? I could clean up my local implementation and send a pull
> request, provided there's interest.
It would be great to decouple “is an Apple platform” from “provides Objective-C
interoperability”!
As you noted, there are two potential use cases for this:
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.
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.
- Doug
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
