Allow Swift types to provide custom Objective-C representations

Joe Groff put together a proposal to import any Objective-C interfaces that use id to Swift as Any instead of AnyObject. This would basically allow Objective-C types to be bridged as value types more easily in Swift (and vice-versa).

The part that caught my attention the most was this.

Bridged value types with established bridging behavior, such as String, Array, Dictionary, Set, etc., should continue to bridge to instances of their corresponding idiomatic Cocoa classes, using the existing internal _ObjectiveCBridgeable protocol. The set of bridged types can be extended in the Swift implementation (and hopefully, eventually, by third parties too) by adding conformances to that protocol.

I am pretty excited about the idea of being able to bridge our own value types to different Objective-C representations. We are using Swift for all of our new code at WDT, but not all of our clients are. We have frameworks that both us and clients use that we are currently rewriting in Swift; but we cannot take complete advantage of Swift’s feature set because our framework needs to work in Objective-C too1.

I did a quick test and having our own value types conform to _ObjectiveCBridgeable does let me transition them to Objective-C NSObject subclasses automatically, but Joe warned me that using it could lead to bugs because the compiler is expecting a closed set up types to conform to that protocol.

The last official news that we heard on this subject was a proposal to open up the _ObjectiveCBridgeable protocol being deferred from Swift 3. This new proposal does not include opening that protocol up yet, but it is a step in that direction.

Update 7/6: This proposal is in review here.

  1. So basically no public structs or enums