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

[Philippe Hausler]

With the introduction of SE-0170 the behavior is a bit more predicable: The rule is that if the value would not loose mantissa representation or significant bits of the representation it will bridge to the target type in all scenarios, no matter if it is created in objc or in swift.

> On May 19, 2017, at 9:00 PM, David Waite via swift-evolution <swift-evolution at swift.org> 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(value: 3.5) as? Int == nil

But

NSNumber(value: 3.5).intValue == 3

> 
> [NSNumber uint64value: UINT64_MAX] ?

NSNumber(value: UInt64.max) as? Int == nil

> 
> What about the float 1e100?

NSNumber(value: 1.0e100) as? Int == nil

>  
> 
> What about boolean 'true’? 

NSNumber(value: true) as? Int == 1

> 
> NaN?

NSNumber(value: Double.nan) as? Int == nil

> 
> -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
> 
> _______________________________________________
> 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/20170520/46406153/attachment.html>