On Mar 6, 2017, at 11:15 AM, Joe Groff <[email protected]> wrote: > >> >> On Mar 4, 2017, at 3:45 PM, Charles Srstka via swift-evolution >> <[email protected]> wrote: >> >>> 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. > > That's an interesting point. We could model the original unbridged signature > as if it were an overload of the method, and `as` coercion would be able to > serve its natural role to pick the unbridged overload if it weren't also > laden with the bridging conversion responsibility.
There’d need to be some special casing to make the compiler prefer the bridged signature over the unbridged when no “as” is present, in order to prevent the compiler whining about ambiguity everywhere, but it would provide some rather useful functionality that currently isn’t available without resorting to hacking it via the Objective-C runtime functions. I think it’d be worth it. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
