[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Douglas Gregor]

> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>> 
>> There are a number of things I'm not really clear on.
>> 
>> * * *
>> 
>> Consider this Objective-C API:
>> 
>> 	ObjCFizzer* myFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>> 	var myFizzer: ObjCFizzer
>> 	var myFizzer: Fizzer
> 
> The latter. The idea is that the importer sees the bridged type is available and substitutes it on all imported signatures. The actual mechanics of that will involve some generated code (thunk) to call the protocol. I could update the proposal to include what the body of that thunk might look like but it didn’t seem terribly interesting.

Right. There will be some thunking the compiler does.

>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this Objective-C API:
>> 
>> 	ObjCMutableFizzer* mutableFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>> 	var myMutableFizzer: ObjCMutableFizzer
>> 	var myMutableFizzer: Fizzer
> 
> The intention there is that it imports as the bridged type so the latter.

I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would be the former.

> 
> 
>> 
>> On the basis of NSArray and friends, I assume they come across like this:
>> 
>> 	var myFizzer: Fizzer
>> 	var myMutableFizzer: ObjCMutableFizzer
>> 
>> Is that correct?
> 
> No

I would have said “yes" ;)

>> 
>> * * *
>> 
>> Foundation classes can sometimes be bridged using an upcast (a plain `as`), which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? If not, will Foundation classes lose that ability?
>> 
>> If this feature can't be expressed with ObjectiveCBridgeable, is this seen as a shortcoming we should try to overcome, or the proper design? I worry about the unnecessary proliferation of exclamation points, especially since many style guides strongly discourage them, which will turn this into an unnecessary proliferation of unnecessary `if let`s.
> 
> This would not be possible. This sort of bridging only works with special magic types because they are known to always succeed. There is no condition under which Swift will fail to convert String to NSString. The compiler/runtime can’t prove that about any arbitrary type.

We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the entry-point

	func bridgeToObjectiveC() -> ObjectiveCType


> For bridging an Objective-C library into Swift, ideally all the APIs will be annotated with SWIFT_BRIDGED so on import the Swift code won’t even be aware the Objective-C type exists. All you’ll see in Swift is the appropriate Swift types. This gives a library (say Photos.framework or UIKit) the chance to provide truly native Swift types by shipping a module with combined Swift and Objective-C code.
> 
> Similarly, going the other direction (an app with Objective-C and Swift code) this proposal eliminates the need to deal with the Objective-C types in Swift.

The ObjC types will still exist (unless explicitly banned via NS_UNAVAILABLE_IN_SWIFT or similar), and can leak through in some cases (e.g., UnsafeMutablePointer<ObjCFuzzer>).

	- Doug

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