<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 29, 2016, at 12:36, Joe Groff via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Nov 29, 2016, at 12:24 PM, Brian Gesiak &lt;<a href="mailto:modocache@gmail.com" class="">modocache@gmail.com</a>&gt; wrote:<br class=""><br class="">Thanks all! It's great to hear that this wouldn't be completely unwelcome -- especially Swift Darwin with Objective-C interop disabled.<br class=""></blockquote><br class="">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.</div></div></blockquote><br class=""></div><div>I’ll go the other way and say I <i class="">do</i>&nbsp;want to discourage this. Swift on other platforms actually <i class="">is</i> 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 <i class="">not</i>&nbsp;add more constraints and configurations expected to work, especially when we’re still porting Swift to different platforms <i class="">without</i>&nbsp;ObjC interop.</div><div><br class=""></div><div>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 <i class="">does</i>&nbsp;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.</div><div><br class=""></div><div>Jordan</div></body></html>