What happens now if you call integerValue if a NSNumber has these values?
> On May 19, 2017, at 9:00 PM, David Waite <da...@alkaline-solutions.com> wrote: > > 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? > > [NSNumber uint64value: UINT64_MAX] ? > > What about the float 1e100? > > What about boolean 'true’? > > NaN? > > -DW > >> On May 19, 2017, at 8:54 PM, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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. >> >> Thanks, >> Jon >> >> >>> On May 16, 2017, at 11:51 AM, Kenny Leung via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> But my argument *is* that optionality is an obvious way to make that >>> decision. >>> >>> 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? >>> >>> -Kenny >>> >>> >>>> On May 15, 2017, at 7:24 AM, T.J. Usiyan <griotsp...@gmail.com >>>> <mailto:griotsp...@gmail.com>> wrote: >>>> >>>> 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. >>>> >>>> TJ >>>> >>>> On Mon, May 15, 2017 at 3:03 PM, Charlie Monroe <char...@charliemonroe.net >>>> <mailto:char...@charliemonroe.net>> wrote: >>>> 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. >>>> >>>> Given that NSNumber is immutable, you get the value semantics anyway... >>>> >>>>> On May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> 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. >>>>> >>>>> On Mon, May 15, 2017 at 5:52 AM, Kenny Leung via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> > On May 12, 2017, at 9:56 AM, John McCall via swift-evolution >>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> > 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. >>>>> >>>>> 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. >>>>> >>>>> -Kenny >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
