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 > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> > On May 12, 2017, at 9:56 AM, John McCall via swift-evolution >>>> > <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
