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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Apr 18 18:48:29 CDT 2017


So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would
expect NSNumber to behave similarly (a notion with which Martin disagrees,
I guess). I don't see a test that shows whether NSNumber behaves or does
not behave in that way.


On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler at apple.com>
wrote:

>
> 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/313496f3/attachment.html>


More information about the swift-evolution mailing list