> On May 20, 2017, at 12:47 PM, Philippe Hausler <[email protected]> wrote:
>
> 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
>> <[email protected] <mailto:[email protected]>> 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
as? now has the closest to predictable behavior, but I would argue that in
terms of generalizing a transform, the meaning of ‘nil’ for an Int? parameter
may not match the behavior one would expect passing in a value which was not an
integer value - say using 3.00000000004 as the argument (due to rounding
errors) rather than the integer 3.
The safest default behavior (should a nullable NSNumber be used to represent an
Int? parameter) would probably be to fatalError out if the user passed a
NSNumber with a value which was not exactly an Int. No NSNumber instance would
be interpreted as ‘nil’ once bridged into Swift.
This still allows the odd edge case of a boolean value being interpreted as 1,
which could cause interface comprehension issues if Bool? was also mapped to
NSNumber in Objc interfaces.
-DW
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
