On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution < swift-evolution@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)
GitHub - phausler/swift at 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@apple.com> wrote:
On Apr 14, 2017, at 22:51, Martin R <martinr448@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@apple.com> wrote:
On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution < > 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> 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
