> 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