<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2017, at 12:25 AM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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=""><div class="">I believe behavior depends on whether the NSNumber is the objc type or swift subtype, and whether you call the NSNumber.intValue or use Int.init?(exactly: NSNumber).</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>That part of the behavior is no longer the case. The bridge only transacts upon one number type (to leverage tagged pointers) and the subclass was removed (since it caused some gnarly inconsistencies) </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="">My point is that there is no intuitive or safe generalized behavior for treating arbitrary NSNumbers as an Int? . If an application or library wants to accept a NSNumber and treat it as an Int?, it should be responsible for declaring that method and implementing that logic.</div></div></div></blockquote><div><br class=""></div><div>But you are absolutely correct; NSNumber should be though of as a AnyNumericValue box where the type of the number is erased but the value is not.</div><div><br class=""></div><div>Interesting cases include:</div><div><br class=""></div><div>NSNumber(value: 3.0) as? Int == 3</div><div><br class=""></div><div>Or </div><div><br class=""></div><div>NSNumber(value: UInt64(121)) as? Int8 == Int8(121)</div><div><br class=""></div><div>The SE-0170 proposal also added initializers for truncating and exactly that work much more on par with the rest of the numeric system in swift. (However it did un-cover a few nasty floating point bugs in the unit tests but the intent of the behavior is matched)</div><div><br class=""></div><div>The other consideration that might be interesting to further your point that nullable NSNumber * as a representation of Int? Is a bit off is that often “optional” integers in objc are actually PoD types with sentry values; e.g. NSNotFound etc. So in reality we would need some sort of annotation on how the bridge of a numeric type should be represented to indicate a nullable value that is exposed as an integer or float etc.</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=""></div><div class="">-DW</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2017, at 11:04 PM, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.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="">What happens now if you call integerValue if a NSNumber has these values?<div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2017, at 9:00 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.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="">When I call such a mapped Swift API that expects an Int? parameter from Objc with a NSNumber initialized with 3.5, what should happen? <div class=""><br class=""></div><div class="">[NSNumber uint64value: UINT64_MAX] ?<br class=""><div class=""><br class=""></div><div class="">What about the float 1e100? </div><div class=""><br class=""></div><div class="">What about boolean 'true’? </div><div class=""><br class=""></div><div class="">NaN?<div class=""><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2017, at 8:54 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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="">I have to side with Kenny on this one. I would find losing nil vs 0 more surprising than NSInteger vs NSNumber. In fact, I was surprised that this doesn’t already cross to a NSNumber. That would be the behavior I expect.<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon<br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 16, 2017, at 11:51 AM, Kenny Leung via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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=""><div class="">But my argument *is* that optionality is an obvious way to make that decision.</div><div class=""><br class=""></div><div class="">If I was writing in pure Objective-C (outside the context of Swift), sometimes I would have methods that take or return int, and sometimes I would have methods that take or return NSNumber. There is never really a surprise as to why. So why would there be a surprise when bridging from Swift?</div><div class=""><br class=""></div><div class="">-Kenny</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 15, 2017, at 7:24 AM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" class="">griotspeak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The argument is not about whether or not it should come through as an object. The argument is about the fact that *sometimes* it would come through as an object and other times it would not. Optionality isn't an obvious way to make that decision.<div class=""><br class=""></div><div class="">TJ</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 15, 2017 at 3:03 PM, Charlie Monroe <span dir="ltr" class=""><<a href="mailto:charlie@charliemonroe.net" target="_blank" class="">charlie@charliemonroe.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">This is not much of an argument given that NSString is an object in ObjC (heap-allocated), String in Swift is an struct and also given that most NSNumber's nowadays are not really allocated, but just tagged pointers.<div class=""><br class=""></div><div class="">Given that NSNumber is immutable, you get the value semantics anyway...</div><div class=""><div class="h5"><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_3753337135911845543Apple-interchange-newline"><div class=""><div dir="ltr" class="">My understanding of the reasoning is that `NSNumber` is an object in Objective-C and not a struct. There is already one level of decision when translating to objc in that regard. Switching between reference semantics/class and value semantics because of optionality is surprising.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 15, 2017 at 5:52 AM, Kenny Leung via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On May 12, 2017, at 9:56 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
> Exporting Int? as an optional NSNumber does not feel obvious and idiomatic when we would export Int as NSInteger. It feels like reaching for an arbitrary solution.<br class="">
<br class="">
</span>I don’t understand this reasoning. I’ve had cause to distinguish 0 from null in both Objective-C and Java, and I would do exactly the same thing.<br class="">
<br class="">
-Kenny<br class="">
<div class="m_3753337135911845543HOEnZb"><div class="m_3753337135911845543h5"><br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>