> On Apr 5, 2016, at 10:14 AM, Douglas Gregor <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.
>
>>>
>>> * * *
>>>
>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
