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

[David Waite]

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> 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
> 
> _______________________________________________
> swift-evolution mailing list
> 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/6add08b2/attachment.html>