[swift-evolution] [Idea] ObjectiveCBridgeable

Douglas Gregor dgregor at apple.com
Thu Mar 17 13:29:15 CDT 2016


> On Mar 17, 2016, at 12:04 AM, Adrian Kashivskyy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I have a couple of ideas regarding the API of ObjectiveCBridgeable. My general thought is to improve upon the existing _ObjectiveCBridgeable protocol, not just make it public. The main idea would be to make it more "Swifty" by:
> 
> 1. Removing inout arguments which look like implementation artifacts and converting them into return values

They are implementation artifacts, because these methods are called by C++ code in the runtime (for dynamic casting), and inout is *much* easier to work with because you know it’s always passed indirectly.

One could almost clearly clean up the primary interface to make it more natural in Swift, then use defaulted implementations for the more runtime-friendly entrypoints.

> 2. Converting static functions to initializers

Yes, that’s reasonable, but see the above.

> 3. Removing isBridgedToObjectiveC() method since it doesn't introduce any useful information

It tells us, dynamically, whether the bridging is actually possible, and is used by the runtime. For example:

func foo<T>(foo: Array<T>) {
  if let obj = foo as? NSArray {
    // whether we get here depends on T, dynamically
  }
}

struct SomeStruct { }

foo([SomeStruct]()) // “Not bridged"
foo([String]())  // “Bridged"

If you look at the implementation of Array’s conformance to _ObjectiveCBridgeable, for example, it dynamically checks whether its element type is _ObjectiveCBridgeable.

Note that isBridgedToObjectiveC is a hack because we don’t have conditional conformances, i.e., we can’t say that Array<T> conforms to _ObjectiveCBridgeable when T is representable in Objective-C. That’s obviously not something to be fixed by this proposal, but hopefully it helps illustrate why isBridgedToObjectiveC matters.

Perhaps you and Russ can work together to clean up _ObjectiveCBridgeable within the proposal? I’ll have more comments on the proposal soon-ish.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160317/a8580f1a/attachment.html>


More information about the swift-evolution mailing list