[swift-dev] [RFC] Modify the build system to enable/disable ObjC interop for any platform

[Jordan Rose]

> On Nov 29, 2016, at 12:36, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> On Nov 29, 2016, at 12:24 PM, Brian Gesiak <modocache at gmail.com> wrote:
>> 
>> Thanks all! It's great to hear that this wouldn't be completely unwelcome -- especially Swift Darwin with Objective-C interop disabled.
> 
> To be clear, I didn't mean to discourage you (or anyone else watching) from adding support for non-Apple Objective-C platforms; I only wanted to make it clear that it almost definitely won't Just Work by trying to compile the existing code for a non-Apple target. Like John said, we should leverage higher-level interfaces in Clang's CodeGen to emit ObjC metadata; right now, we hardcode the Apple layouts of everything.

I’ll go the other way and say I do want to discourage this. Swift on other platforms actually is benefitting from not having ObjC interop—as a tiny example, dynamic casts don’t have to do something different to account for Objective-C’s duck typing. The CoreFoundation used in swift-corelibs-foundation ought to mimic the layout of Swift classes, not Objective-C ones, so now you can’t use Foundation. I’m being pessimistic, but if this is a “just-for-fun” project I think there are better ones, and if this is a “I want to ship something” project I think it’ll run into trouble down the line. I’d rather not add more constraints and configurations expected to work, especially when we’re still porting Swift to different platforms without ObjC interop.

Swift-without-ObjC on Darwin is a more interesting project: it gives us a better ability to test the corelibs properly, among other things. I’m not sure whether you’d be able to mix that in a project that does use Swift-with-ObjC, though—the runtimes might step on each other. Still, making that side configurable seems both more useful and more likely to succeed.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161130/385cab32/attachment.html>