I think I understand what you’re saying, but that doesn’t seem to be what Charles is saying in #3.
-Kenny > On Mar 4, 2017, at 6:15 PM, Jaden Geller <jaden.gel...@gmail.com> wrote: > > 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@swift.org <mailto:swift-evolution@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 <cocoa...@charlessoft.com >>> <mailto:cocoa...@charlessoft.com>> wrote: >>> >>>> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
