No, that’s pretty much exactly what I was saying. Charles
> On Mar 4, 2017, at 9:12 PM, Kenny Leung via swift-evolution > <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[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] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > 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
