[swift-evolution] Followup after in-the-field feedback for SE-0170

[Itai Ferber]

Those cases will produce `nil`. "Should" is a matter of expectation, but 
I think that it’s reasonable behavior since it feels truer to the 
intent the `exactly:` methods.

On 16 Jun 2017, at 16:23, Jordan Rose via swift-evolution wrote:

> > On Jun 14, 2017, at 13:59, Philippe Hausler via swift-evolution 
> <swift-evolution at swift.org> wrote:
>>
>>
>>
>>> On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution 
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 
>>> wrote:
>>>
>>>
>>> on Wed Jun 14 2017, Philippe Hausler <swift-evolution at swift.org 
>>> <mailto:swift-evolution at swift.org>> wrote:
>>>
>>>> After implementing the proposal
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md 
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md 
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>>
>>>> we have gotten some initial feedback.
>>>>
>>>> It seems that there is definitely a fair amount of confusion and 
>>>> heartache for dealing with Float
>>>> and Double values being bridged.
>>>>
>>>> Specifically the cases like:
>>>>
>>>> NSNumber(value 0.1) as? Float
>>>>
>>>> which with the current implementation will return nil since the 
>>>> Double value 0.1 cannot be
>>>> represented exactly as a Float.
>>>>
>>>> It seems like the overwhelming majority of users know full well 
>>>> that
>>>> Float will result in a loss of precision (hence why they chose that
>>>> type over Double). This means that the floating point bridges for
>>>> Double, Float, and CGFloat should not be the pedantic “exactly” 
>>>> cases
>>>> but instead infer the conversion intent of a lax/approximated 
>>>> version.
>>>
>>> +1
>>>
>>>> So in short: for the betterment of the API ergonomics, the floating
>>>> point types as destinations will be pulled back to their initial 
>>>> Swift
>>>> 3 behavior.
>>>>
>>>> Additionally to aide appropriate migration to the appropriate
>>>> truncating/exactly initializers the un-labeled, deprecated in Swift 
>>>> 4,
>>>> plain init methods to the numeric types with an NSNumber will now 
>>>> be
>>>> annotated with the suggested replacements.
>>>
>>> Sorry, I don't quite understand what that last paragraph implies.  
>>> Could
>>> you describe what will be deprecated and what will be suggested 
>>> instead?
>>
>> https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4 
>> <https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4>
>>
>> So this is just an annotation of renaming to the init(truncating:)
>
> How about cases where the value is a double that's greater than 
> Float.greatestFiniteMagnitude? Should/Will that produce 'nil' or 
> Float.infinity?
>
> Jordan


> _______________________________________________
> 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/20170616/9084e269/attachment.html>