> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution > <[email protected]> wrote: > > Speaking from a position of total ignorance here, but I’ll do it anyway :-) > > How is the implicit dynamic bridging any different from implicit static > bridging? If I have an Objective-C method like > > - (NSArray<SuctionBall>)getAllSuctionBalls > > It would get translated into > > func getAllSuctionBalls() -> [SuctionBall] > > Where an NSArray is being implicitly bridged to a Swift array. Since such an > implicit conversion exists anyway, what’s the harm in it happening when you > do > > let swiftSuctionBalls = getSomething() as [SuctionBall]
1. The bridging described above is necessary, because you’re calling an API in another language. Some kind of bridging has to be involved for that to work at all, and we all understand that. 2. The bridging above doesn’t abuse a language construct that typically has a completely different meaning (“as” as compile-time type coercion, with no runtime effects). 3. If we fix “as” so that it only means type coercion, we could finally have a way to avoid the bridging behavior above; i.e. ‘getAllSuctionBalls() as NSArray’ to leave the returned value in its original form as an NSArray, rather than bridging it to Swift and then back. This would be really useful for certain situations like NSURL’s -fileReferenceURL which gets mangled by the bridge, and it could also provide a potential performance optimization when getting values that are just going to get passed to other Objective-C APIs afterward. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
