Thanks all! It's great to hear that this wouldn't be completely unwelcome -- especially Swift Darwin with Objective-C interop disabled.
I'll try and send a patch sometime soon -- although I'm busy with work stuff, so at the latest it'll be sometime in December... in the meantime, I created a task for it: https://bugs.swift.org/browse/SR-3292. Feel free to comment there, or to claim the task for yourself. :) - Brian Gesiak On Mon, Nov 28, 2016 at 5:02 PM, John McCall <rjmcc...@apple.com> wrote: > > On Nov 28, 2016, at 1:33 PM, Joe Groff via swift-dev < > swift-dev@swift.org> wrote: > >> 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, 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>. > >> > >> 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>. 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. > > > > It's not only the build system, but the IRGen and runtime implementation > of ObjC interop is also heavily biased towards Apple's implementations of > the ObjC runtime and Foundation on Darwin. Just changing all those #ifdef > __APPLE__ s to #if SWIFT_OBJC_INTEROP is not going to get you very far > working with another ObjC implementation. As Doug noted, supporting > ObjC-less Darwin would on the other hand be very useful! > > Right. If you really wanted to support using Swift with a different > Objective-C ABIs, I think the first step would be to do some work in clang > to expose an abstract API for building classes. You'd still need *some* > ABI-specific code in Swift IRGen, I expect, but it ought to be possible to > re-use the majority of Clang's ObjC targeting code. > > John. >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev