[swift-corelibs-dev] NSJSONSerialization and bridging

[Tony Parker]

Hi Dave,

> On Mar 5, 2016, at 7:12 AM, David P Grove <groved at us.ibm.com> wrote:
> 
> swift-corelibs-dev-bounces at swift.org wrote on 03/04/2016 05:44:31 PM:
> > 
> > We haven’t really made any progress in this area, unfortunately.
> > 
> > It would be awesome if someone could take up the banner of getting 
> > bridging to work on non-ObjC platforms. 
> 
> Hi Tony,
> 
> I'd be happy to be some of the development "muscle" to help execute a plan, but I don't yet have the overall grasp of the Swift implementation needed to propose a plan.
> 
> I think the libdispatch import/object model task I'm working on now is probably a useful warmup exercise, but even after that is done I expect I'll need some pointers on how to tackle the bigger problem of bridging in general.
> 
> Is there are chance there is a design worked out for bridging alternatives on Linux that could be shared?
> 
> thanks,
> 
> --dave
> 

Great! I’ll try to summarize some of the issues as I understand them. We can follow up later once you’ve started.

To simplify it to one sentence: The standard library and sometimes the compiler conflate the concept of “presence of the Objective-C runtime” with “presence of Foundation.”

Take a look at this file:

https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeObjectiveC.swift <https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeObjectiveC.swift>

The entire thing is #ifdefed out on non-ObjC runtimes. Now, it’s true that without the ObjC runtime we do not have autorelease — but we could still convert from NSArray (reference) to Array (struct). Here is another part to it:

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift <https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift>
https://github.com/apple/swift/blob/master/stdlib/public/core/SwiftNativeNSArray.swift

Some of the bridging logic is done via conformance to a protocol that is known to the compiler (_ObjectiveCBridgeable). Some of it is Swift subclasses of Foundation types like NSArray that are used in the implementation of that protocol.

Now, one could imagine some future where we don’t need bridging because everything is implemented in Swift. However, in order to get something going without having to rewrite the world (and also to leverage good code that we know works the same on all platforms), we started with existing C code in CoreFoundation. When CF creates a CFArrayRef and returns it to the Swift code, we are faced with the same bridging problem we have on Darwin — CFArray is a fundamentally different representation than a ‘native’ Swift Array. Do we pay an O(n) conversion cost, or do we sometimes choose to back the Swift array with the CFArray? On Darwin we sometimes back it with the NSArray; especially when the contents are heterogeneous. On Linux we have no choice and we have to construct a new Swift array each time.

I don’t want to create a sweeping new design for bridging. I think we should just make the environment as similar as possible on Darwin and Linux. This means finding out which things are truly not possible without Objective-C (AutoreleasingUnsafeMutablePointer, for example, which we’ve been excising from our swift-corelibs-foundation API) and separating them from things which are more about type conversion.

It could be the case that we want to put the bridging logic on Linux into swift-corelibs-foundation instead of the standard library. I’m ok with that. On Darwin, the SDK is present which makes it easy to link Foundation (it’s always there). This is trickier in the Linux build environment.

There may be some tricks that the standard library uses (built-ins, etc.) that are not possible to use outside of it, though, so we may need to have some thunks there.

So in summary: no grand re-design; we should just try to get our existing design to work on Linux as closely as we can to how it works on Darwin.

- Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160306/1d6aa28e/attachment.html>