[swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler]

> On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon at apple.com> wrote:
> 
>> 
>> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff at apple.com> wrote:
>> 
>> 
>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/5ca4b245/attachment.html>