Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix parsing foreign currency strings #1074
base: main
Are you sure you want to change the base?
Fix parsing foreign currency strings #1074
Changes from 2 commits
10091ea
6b31a63
85616ad
9a1e617
876db35
a245a41
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This type is part of the
Codable
format of a number of public types conforming toParseStrategy
, e.g.IntegerParseStrategy
. So while this solution means the Codable conformance forDecimal.FormatStyle.Currency
is backwards compatible, your decoding test would still fail forIntegerParseStrategy
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you meant this is a var in
IntegerParseStrategy
andFloatingPointParseStrategy
and friends ... OK we need tests for that too. ThanksThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ParseStrategy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another attempt: In 9a1e617 I removed the stored property
numberFormatType
fromIntegerParseStrategy
andFloatingPointParseStrategy
. That means the we no longer preservenumberFormatType
in serialization, andnumberFormatType
in previousCodable
representation will be ignored from now on.This is ok because the information is already provided by the other variable,
formatStyle
. In other words,numberFormatType
has always been redundant. I also liked this because the previous serialization output feels like we're leaking internal information.There is indeed a slight chance of regression -- if you manually craft an archive where
numberFormatType
represents different configurations from that offormatStyle
, previously we'd favor what's represented bynumberFormatType
, but now we'd favorformatStyle
. I think this risk is low enough though. Besides, I don't think we ever guarantee compatibility for manually crafted archives.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests incorrectly assumed that a currency style with "USD" code but "fr_FR" locale can correctly match a currency string with EUR symbol (
"57 379,00 €"
). This isn't correct, and is exactly what this bug is about: we only respect the locale regional currency, but ignore the currency code.