Enablement of ObjectiveCBridgeable protocol for Linux #1994
Conversation
|
The idea here is to start work on enabling bridging to work on all platforms equally. |
stdlib/public/runtime/Casting.cpp
Outdated
There was a problem hiding this comment.
This entry point should not be needed on the native runtime. There are no unknown objects in the native runtime, all objects are Swift objects.
|
I enabled two existing test cases on Linux that touch on ObjectiveCBridgeable. My original thinking is that most of the testing of the functionality would be done as part of testing swift-corelibs-foundation. |
|
Sorry, but we can't rely on other repositories for complier and standard library testing. |
|
It's unfortunate that many of the test cases already in swift/tests for ObjectiveCBridgeable import Foundation (grep 'import Foundation' in tests/1_stdlib). It would be nice to simply be able to start enabling them on Linux using swift-corelibs-foundation. |
|
Do we want bridging to work on Linux? If corelibs Foundation is written mostly in Swift, and is doing things like widening AnyObject to Any to better interop with arbitrary native Swift types, a lot of our motivation for bridging on Apple platforms goes away. |
|
My understanding from Tony is that the goal (which maybe is just a medium-term tactical improvement, not the ultimate destination) is that we want to reduce the cross-platform differences in bridging. On Linux, we will be bridging between two Swift types (eg String and NSString), but we want the end user program to look the same ( |
|
Fair enough, I can see the desire for functional parity. I would hope long term we can reduce the need for the runtime magic, though ObjectiveCBridgeable remains useful for static bridging of imported C/ObjC interfaces. |
|
swift-corelibs-foundation isn't actually written mostly in Swift, it's written mostly in C (via CoreFoundation). This includes things like plist parsing. They are creating CFTypeRefs (which we've laid out like SwiftObjects), but having to go through a manual conversion instead of having our usual bridging in place is pretty expensive. |
|
IIUC, that isn't what this provides though; to avoid the manual conversion, you'd need to implement support in |
|
Optimistically squashed into a single commit and updated the commit comment to indicate that the change is also enabling the handful of existing testcase for ObjectiveCBridgeable that don't require Foundation or Objective-C to pass (all pass in my Linux environment with this change). |
Make the ObjectiveCBridgeable protocol available and minimal pieces of the runtime support for it available even without an Objective-C runtime. This is motivated by supporting bridging in swift-corelibs-foundation on Linux via the compiler/runtime support provided by ObjectiveCBridgeable. Also enable the six existing testcases for ObjectiveCBridgeable that don't import Foundation or truly rely on an Objective-C runtime being present.
|
rebased to master as of 4/25 |
|
@gribozavr @parkera I've rebased to refresh the change set. I think this is ready to go....anything else we need to do? Thanks. |
|
@parkera Any feedback from the Swift core team on whether reusing ObjectiveCBridgeable like this on Linux is going to fly? |
|
Hm, nothing yet. @gribozavr, @dabrahams, @DougGregor : can you help weigh in on this? It obviously became more important due to SE-0069. |
|
@parkera, the code looks basically OK to me. Forgive my cluelessness, but what, specifically, are you asking us to weigh in on? “Whether reusing ObjectiveCBridgeable like this on Linux is going to fly” seems like a big open-ended question to me, and though I’ve read the foregoing comments I’m not sure I understand what we’re trying to accomplish. |
|
If we accept SE-0083, we wouldn't need this runtime magic. The bridging conversions could then be provided as normal API. |
|
@dabrahams I'll try to make this more concrete. Today, the bridging code here is guarded by the presence of ObjC interop. However, in order to make things like NSData -> struct Data work on Linux, we will need the bridging to work there as well. This was already the case for NSArray -> struct Array, but by adding a lot of new bridged types in Foundation, it became a more pressing problem to solve. |
|
There's a much larger design point here. Bridging between values and objects is an important part of Objective-C interoperability (this is part of the discussion to be had for SE-0083), but it doesn't necessarily belong in Swift when there isn't an Objective-C runtime. |
|
@DougGregor you're clearly aware of how important the ability to bridge is for the Foundation value types work, but without support on Linux we will introduce an even larger source incompatibility between platforms. What is your proposed solution to that? |
|
I think this behavior is not needed on Linux, and instead the Corelib Foundation library should be adapted to use value types. I would like to contribute to that, where can I start? |
|
Not needed; closing. |
7 participants
What's in this pull request?
Resolved bug number: (SR-)
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Note: Only members of the Apple organization can trigger swift-ci.
Make the ObjectiveCBridgeable protocol available
and minimal pieces of the runtime support for it
available even without an ObjectiveC runtime.
This is motivated by supporting bridging in
swift-corelibs-foundation on Linux via the
compiler/runtime support provided by
ObjectiveCBridgeable.