<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 Nov 10, 2016, at 1:44 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><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 Nov 10, 2016, at 11:42 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 10, 2016, at 1:34 PM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 10, 2016, at 10:30 AM, Philippe Hausler <<a href="mailto:phausler@apple.com" class="">phausler@apple.com</a>> wrote:<br class=""><br class="">So I think there are a few rough edges here not just the hashing or equality. I think the issue comes down to the subclass of NSNumber that is being used - it is defeating not only hashing but also performance and allocation optimizations in Foundation.<br class=""><br class="">So what would we have to do to get rid of the “type preserving” NSNumber subclass?<br class=""></blockquote><br class="">The type-preserving subclasses remember the exact Swift type that a value was bridged from, to preserve type specificity of casts so that e.g. `0 as Any as AnyObject as Any as? Float` doesn't succeed even if the Any <-> AnyObject round-trip involves ObjC, thereby providing somewhat more consistent behavior between Darwin and Corelibs-based Swift. If we were willing to give that up, and say that NSNumbers just flat-out lose type info and can cast back to any Swift number type, then it seems to me we could use the pure Cocoa subclasses.<br class=""></blockquote><br class="">Would these only be value-preserving casts and return nil if information loss would occur? I think that might be preferable anyway. Maybe I’m just not thinking hard enough, but when would the original type information be important as long as information isn’t lost? When I interact with these casts and NSNumber (JSON parsing, etc) I generally *do not* want an attempted cast that would be value-preserving to ever fail.<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="">I'm inclined to agree that the cast should be value-preserving rather than type-preserving. There was concern about the behavior being different on Darwin and Linux, which is why we try to be type-preserving so that pure Swift code that uses number values with Any or other polymorphic interfaces behaves consistently with Cocoa Foundation code that has to traffic in NSNumber for the same effect.</span><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=""></div></blockquote><div><br class=""></div><div>Are you saying that Swift on Darwin can’t have value-preserving behavior? It seems like I’m missing something here. If value-preserving is the desirable behavior can you elaborate on the specific challenges getting in the way of having that behavior everywhere?</div><br class=""><blockquote type="cite" class=""><div class=""><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="">-Joe</span></div></blockquote></div><br class=""></body></html>