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

[Russ Bishop]

> On Apr 5, 2016, at 10:14 AM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>>> 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.
> 

Hmmm… So all subclasses are hidden as far as the interface is concerned (and the ambiguity rules)? I’m fine with that, it seems like it suites the class cluster approach just fine.


> 
>>> 
>>> * * *
>>> 
>>> 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
> 

It does seem strange that this is asymmetrical but I don’t know that it is worth the complexity to introduce an extended protocol to declare a type has a bi-directional always-succeeds bridging conversion.


> 
>> 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

Agreed, that’s what I meant by "things like performSelector, context objects, …” :)


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