> On Apr 18, 2017, at 9:22 AM, Stephen Canon <[email protected]> wrote:
>
>>
>> On Apr 18, 2017, at 12:17 PM, Joe Groff <[email protected]> wrote:
>>
>>
>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> It seems Float.init(exactly: NSNumber) has not been updated to behave
>>> similarly?
>>>
>>> I would have to say, I would naively expect "exactly" to behave exactly as
>>> it says, exactly. I don't think it should be a synonym for
>>> Float(Double(exactly:)).
>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution
>>> <[email protected]> wrote:
>>> I posted my branch and fixed up the Double case to account for your
>>> concerns (with a few inspired unit tests to validate)
>>>
>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>>
>>> There is a builtin assumption here though: it does presume that the swift’s
>>> representation of Double and Float are IEEE compliant. However that is a
>>> fairly reasonable assumption in the tests.
>>
>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)?
>> NSNumber's behavior would ideally be consistent with that.
>
> The implementation is essentially just:
>
> self.init(other)
> guard Double(self) == other else {
> return nil
> }
>
> i.e. if the result is not equal to the source when round-tripped back to
> double (which is always exact), the result is nil.
>
> – Steve
Pretty much the same trick inside of CFNumber/NSNumber
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
