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

[Douglas Gregor]

> On Apr 5, 2016, at 11:36 AM, Russ Bishop <xenadu at gmail.com> wrote:
> 
> 
>> On Apr 5, 2016, at 10:14 AM, Douglas Gregor <dgregor at apple.com <mailto: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.

Not “hidden”; they’re accessible and not bridged.

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

It is a little odd; we have isBridgedToObjectiveC and bridgeToObjectiveC, where we could possibly have the latter produce an ObjectiveCType? and remove the former.

	- Doug

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