> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution
>> <[email protected]> wrote:
>>
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>>
>> There are a number of things I'm not really clear on.
>>
>> * * *
>>
>> Consider this Objective-C API:
>>
>> ObjCFizzer* myFizzer;
>>
>> Which of these represents how it is imported?
>>
>> var myFizzer: ObjCFizzer
>> var myFizzer: Fizzer
>
> The latter. The idea is that the importer sees the bridged type is available
> and substitutes it on all imported signatures. The actual mechanics of that
> will involve some generated code (thunk) to call the protocol. I could update
> the proposal to include what the body of that thunk might look like but it
> didn’t seem terribly interesting.
Right. There will be some thunking the compiler does.
>> 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.
>
>
>>
>> On the basis of NSArray and friends, I assume they come across like this:
>>
>> var myFizzer: Fizzer
>> var myMutableFizzer: ObjCMutableFizzer
>>
>> Is that correct?
>
> No
I would have said “yes" ;)
>>
>> * * *
>>
>> 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
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
