[swift-evolution] Swift's Optional Int as NSNumber in Objective-C

[Jonathan Hull]

What happens now if you call integerValue if a NSNumber has these values?


> On May 19, 2017, at 9:00 PM, David Waite <david at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 <griotspeak at gmail.com <mailto:griotspeak at 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 <charlie at charliemonroe.net <mailto:charlie at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> > On May 12, 2017, at 9:56 AM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170519/b448732e/attachment.html>