> On Apr 5, 2016, at 11:36 AM, Russ Bishop <xen...@gmail.com> wrote:
>
>
>> On Apr 5, 2016, at 10:14 AM, Douglas Gregor <dgre...@apple.com
>> <mailto:dgre...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
