[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

[Joe Groff]

> On Mar 4, 2017, at 3:45 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> 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.

-Joe