<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Mar 6, 2017, at 11:15 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Mar 4, 2017, at 3:45 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Speaking from a position of total ignorance here, but I’ll do it anyway :-)<br class=""><br class="">How is the implicit dynamic bridging any different from implicit static bridging? If I have an Objective-C method like<br class=""><br class="">- (NSArray<SuctionBall>)getAllSuctionBalls<br class=""><br class="">It would get translated into<br class=""><br class="">func getAllSuctionBalls() -> [SuctionBall]<br class=""><br class="">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<span class="Apple-converted-space"> </span><br class=""><br class="">let swiftSuctionBalls = getSomething() as [SuctionBall]<br class=""></blockquote><br class="">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.<br class=""><br class="">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).<br class=""><br class="">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.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote><br class=""></div>There’d need to be some special casing to make the compiler prefer the bridged signature over the unbridged when no “as” is present, in order to prevent the compiler whining about ambiguity everywhere, but it would provide some rather useful functionality that currently isn’t available without resorting to hacking it via the Objective-C runtime functions. I think it’d be worth it.<div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>