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. > > On Apr 15, 2017, at 13:12, Philippe Hausler <[email protected]> wrote: > > > > On Apr 14, 2017, at 22:51, Martin R <[email protected]> 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 <[email protected]> wrote: > > > On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution < > [email protected]> 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 < > [email protected]> 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 <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
