I think you’re misunderstanding it. The goal is to only provide bridging at the language boundary (via the importer). The keyword `as` would no longer invoke bridging behavior, but would simply provide extra static type information to help with inference.
Cheers, Jaden Geller > On Mar 4, 2017, at 4:33 PM, Kenny Leung via swift-evolution > <[email protected]> wrote: > > So this proposal would not only change the meaning of “as”, but would require > changing all bridged Objective-C API to remove any implicit conversions? > > -Kenny > > >> On Mar 4, 2017, at 3:45 PM, Charles Srstka <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution >>> <[email protected] <mailto:[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
