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

[Xiaodi Wu]

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.
>
> On Apr 15, 2017, at 13:12, Philippe Hausler <phausler at apple.com> wrote:
>
>
>
> On Apr 14, 2017, at 22:51, Martin R <martinr448 at gmail.com> wrote:
>
> Thank you for the response, but I have more questions. Will
>
>     Float(exactly: NSNumber(value: Double.pi))
>
>
> This will succeed in that the value is representable without loosing
> mantissa
>
>
> fail because Float cannot represent the number Double.pi exactly? Or
>
>     Double(exactly: NSDecimalNumber(string: "1.9”))
>
>
> Again it would be representable without losing mantissa but…
>
>
> because Double cannot represent the decimal fraction 1.9 exactly?
>
>
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope
> of this proposal (it is it’s own type and bridges to Decimal)
>
>
> I find it difficult to evaluate the proposal without a description of the
> intended behavior of the "exact" conversions which covers all possible
> combinations (integers, floating point values, booleans). At present, the
> behavior is described only for stored integer types.
>
>
> I can post the patch but the real machinery is in NSNumber itself. The
> primary test is that if the value can round trip as the expected type and
> evaluate to equal to a NSNumber it will.
>
> The conversion roughy is a cast to and from the stored type;
>
> extension Double {
> init?(exactly number: NSNumber) {
> let value = number.doubleValue
> guard NSNumber(value: value) == number else { return nil }
> self = value
> }
> }
>
> The effective result of this is a verification of the stored type being
> equal to the fetched value. But specifically this only traverses via tagged
> pointers (if the are present). It is worth noting that this is not the
> exact implementation but an approximation with public apis.
>
> Overall this is by far a better behavior than just permissively allowing
> all conversions (which is the current alternative of doing nothing…). As
> one of the responsible maintainers for NSNumber I would claim that a
> generally permissive cast as it is today is incorrect usage of NSNumber.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 23:23, Philippe Hausler <phausler at apple.com> wrote:
>
>
> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Apologies if I am overlooking something, but it seems to me that the
> proposal does not clearly define the behavior of the "exact" conversions
> between integer and floating point values. Does
>
>     Int(exactly: NSNumber(value: 12.34))
>
>
> The exact value of a float or double constructed NSNumber will only happen
> for integral values: e.g. 1.0, -32.0 etc
>
>
> fail because Int cannot represent the number exactly? Or are floating
> point values truncated silently and the conversion to an integer fails only
> if it overflows? And the other way around: Does
>
>     Double(exactly: NSNumber(value: Int64(9000000000000000001)))
>
> fail because Double cannot represent the number exactly?
>
>
> I believe this will fail because the Int64 value will exceed the mantissa
> representation of the Double from my current implementation.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Apologies, if you are reading this in HTML the links appear to be pointing
> to the incorrect proposal.
>
> Here is the corrected link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
> On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen at apple.com> wrote:
>
> Hello Swift community,
>
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now
> and runs through the Friday after next, April 14th. The proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
> Reply text
>
> Other replies
>
> *What goes into a review?*
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Ben Cohen
> Review Manager
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> 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/20170418/30e2d1d6/attachment.html>