-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initializing a currency with Decimal.nan provides unexpected data #17
Labels
bug
Something isn't working
Comments
Mordil
added a commit
that referenced
this issue
Feb 22, 2020
Motivation: While working on linux CI (#7) and due to bug #17, many holes in the current implementation were found. These include issues with handling NaN representations, integer overflow, performance, and code reusability. The primary issue is that the default implementations for protocol requirements were not playing nicely with each other, especially while compiling with Swift 5.2. Modifications: - Change: `init(exactly)` to be `init<T: BinaryInteger)(minorUnits:)` to be more forgiving to the types, and to avoid confusion with `Numeric` initializers - Change: `init(_:)` to be `init?(amount:)` to properly handle NaN values as well as to avoid `init(floatLiteral:)` accidental usage due to SE-0213 - Change: Code documentation to be more thorough and clear - Change: `inverse` from a computed property to `negated()`, catching overflow - Change: Localization from string interpolation is now explicit with `\(localize: <value>)` as the new form, to avoid clashes with the default interpolation behavior and default parameters Result: Implementations should be less buggy, Currency should compile in Swift 5+, with happier developers using the library.
Mordil
added a commit
that referenced
this issue
Feb 23, 2020
Motivation: While working on linux CI (#7) and due to bug #17, many holes in the current implementation were found. These include issues with handling NaN representations, integer overflow, performance, and code reusability. The primary issue is that the default implementations for protocol requirements were not playing nicely with each other, especially while compiling with Swift 5.2. Modifications: - Change: `init(exactly)` to be `init<T: BinaryInteger)(minorUnits:)` to be more forgiving to the types, and to avoid confusion with `Numeric` initializers - Change: `init(_:)` to be `init?(amount:)` to properly handle NaN values as well as to avoid `init(floatLiteral:)` accidental usage due to SE-0213 - Change: Code documentation to be more thorough and clear - Change: `inverse` from a computed property to `negated()`, catching overflow - Change: Localization from string interpolation is now explicit with `\(localize: <value>)` as the new form, to avoid clashes with the default interpolation behavior and default parameters Result: Implementations should be less buggy, Currency should compile in Swift 5+, with happier developers using the library.
This should be fixed in the next version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setting a breakpoint in
init(_:)
shows that all the Decimal operations properly respond with.nan
.The issue is
NSDecimalNumber(decimal:)
when returning theint64Value
The text was updated successfully, but these errors were encountered: