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 <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 <phaus...@apple.com> wrote: > > > >> On Apr 14, 2017, at 22:51, Martin R <martinr...@gmail.com >> <mailto:martinr...@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 <phaus...@apple.com >>> <mailto:phaus...@apple.com>> wrote: >>> >>>> >>>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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 >>>>> >>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md> >>>>> >>>>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_co...@apple.com >>>>>> <mailto:ben_co...@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 >>>>>> >>>>>> <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 >>>>>> <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 >>>>>> >>>>>> <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 >>>>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Ben Cohen >>>>>> Review Manager >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
