<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 2, 2017, at 4:24 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2017, at 3:09 PM, Jaden Geller <<a href="mailto:jaden.geller@gmail.com" class="">jaden.geller@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1. I’ve always found the bridging casting behavior confusing. Definitely would agree with removing it—especially given the interop problems—but only if a good solution was found for imported APIs.<div class=""><br class=""></div><div class="">With `NSNumber`-involving APIs, I think it might be reasonable to add an Objective-C annotation to specify what numeric type ought to be used (instead of Any). For example, `-(NSNumber<UInt32> *) foo` is a straw-man syntax for specifying that a number should be imported as `UInt32` in Swift.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That might be a nice ObjC addition, but I think we could pursue that independently.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What other APIs involve this dynamic through-`Any` bridging behavior? It might make sense to make a comprehensive list. Another I can think of is `NSJSONSerialization`. It would be much more difficult to remove bridging behavior here without new language features… Additionally, NSNumber is still problematic—what should be the numeric type of a JSON number? If only we had integer and floating point existentials…</div></div></div></blockquote><div class=""><br class=""></div><div class="">In general, anywhere you get an `id` behavior—return values, block callback inputs, and yeah, untyped NSArrays and NSDictionarys. In the case of JSON, you might be able to use Double, but for the full range of types plists support, IMO you arguably ought to work directly with the NSNumber interface. That's likely the only implementation that'd make sense in corelibs foundation, for instance. (Maybe with the new integer protocols we could introduce an `AnyNumeric` type-erased container…)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Perhaps Objective-C APIs that return `id`, when called from Swift, ought to <b class="">eagerly perform bridging</b> for the boxed value into the respective Swift type? Then `as` would no longer perform this weird behavior; it would just happen by default <b class="">for all values return from Objective-C APIs</b>. No need to store an extra bit on the existential and introduce inconsistent behavior… </div></div></div></blockquote><div class=""><br class=""></div><div class="">The problem is that we can't know, without further input from the compiler, what bridging is needed, if any. The interface may intend to provide an NSNumber, or an NSString backed by NSTextStorage or Core Data, or something like that, for which you wouldn't want to go through the bridge.</div></div></div></div></blockquote><div><br class=""></div><div>Ah, that is problematic… Thanks for the explanation.</div><div><br class=""></div><div>Do you anticipate that Swift will ever support arbitrary subtype relationships (like `Int8` as a subtype of `Int`, for example). If so, then would the current bridging behavior be that odd? All the numeric types could be declared to be a subtype of `NSNumber` by some Foundation overlay, etc., and the behavior would be the same as it is today.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">There obviously ought to be a way to opt out of this if you want the original type. Perhaps the compiler could detect conversions back to Objective-C types are <b class="">optimize away the round-trip</b>? For example, `try! JSONSerialization.jsonObject(with: data)` would be implicitly converting to a Swift type (wrapped in an `Any`) while `NSString(try! JSONSerialization.jsonObject(with: data) as! String)` would skip the roundtrip conversion via the optimizer.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The compiler already does some of this. If you pass a value type as an `Any` parameter, it will bridge directly to the parameter's bridged object type instead of going through Any and dynamically bridging first.</div></div></div></div></blockquote><div><br class=""></div><div>That’s super cool! 🙌</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">-Joe</div></div></div></div></blockquote></div><br class=""></body></html>