> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution