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

[Jaden Geller]

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 <swift-evolution at swift.org> 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 <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> 
>>> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org <mailto: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.
>> 
>> Charles
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170304/a2240fd6/attachment.html>