> On Nov 29, 2016, at 12:36, Joe Groff via swift-dev <swift-dev@swift.org>
> wrote:
>
>
>> On Nov 29, 2016, at 12:24 PM, Brian Gesiak <modoca...@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
