cc @itaiferber

It's possible for us to attempt a few things in Decimal's constructor — attempting to initialize from a Double, Float, String, etc. We can also allow JSONEncoder/JSONDecoder to intercept Decimal values to output correctly.

@swift-ci create

Comment by Jesper Lindholm (JIRA)

That sounds like a good idea. The following is a good example of why going through an IEEE 754 binary floating point type like Double or Float is best avoided if at all possible:

let json = "{\"num\": 0.1, \"otherNum\": 0.10000000000000001}"
let jsonData = json.data(using: .utf8)!

struct PayloadDouble: Codable {
    let num: Double
    let otherNum: Double
}

let jsonDecoder = JSONDecoder()
do {
    let decodedObjectDouble = try jsonDecoder.decode(PayloadDouble.self, from: jsonData)
    let num = decodedObjectDouble.num
    let otherNum = decodedObjectDouble.num
    let areEqual = num == otherNum // -> true !!!
} catch {
    error
}

The example above is Double because that's all that will run now, but if the type above was Decimal and decoding meant going through Double, that would still happen even for Decimal. Even if you are in the odd position that you use Decimal but don't care about the precision, re-encoding the JSON wouldn't roundtrip to the same data.

It's possible for us to attempt a few things in Decimal's constructor — attempting to initialize from a Double, Float, String, etc.

For decimal numbers, it would be best if it could construct a Decimal directly from a NSDecimalNumber. As far as I know the underlying NSJsonSerialization library will attempt to parse numbers that do not fit in `long long` as NSDecimalNumber.

Regarding initialisation from Strings, I don't think that is a good idea, because what locale would it attempt to use? The locale would have to be configurable, but that also only covers a restricted set of use cases where the string has a format supported by Decimal.
Decimal has

init?(string: String, locale: Locale? = default), 

But leaving the locale as default is only really recommended for user input, not for parsing values in a known format, such as from a Json API.

Completed with apple/swift#10553

@bobergj Bridging to/from NSDecimalNumber is exactly the way to go, and this is what I've done. Should maintain compatibility in a wide variety of cases.

Also, in the case of string conversion, we would likely use the en_US_POSIX locale by default — for non-standard cases, it seems reasonable to require custom handling of such values.

@itaiferber Should you decide to go for "en_US_POSIX" by default, you may want to fix https://bugs.swift.org/browse/SR-5326

Comment by Jesper Lindholm (JIRA)

Sweet - this seems to solve the problem. Looking forward to seeing this in an upcoming beta. Quick work!

Comment by Bill Boland (JIRA)

I'm sorry in advance if this is not the proper forum for such a question. I was looking to see how Decimal may have adopted the Codable protocol as I have many JSON objects using Decimal values. We found that they are not always representable accurately as Double/Float. For example, in the Playground example to this issue, if the value is 0.81,

let json = "{\"num\": 0.81}"

the resulting decoded Decimal is printed as 0.8100000000000002048 (with Xcode 9 beta 6). So, we tend to encode and decode to/from Strings instead.

I was intrigued by the comments about using a String representation (which is what we would desire to maintain accuracy). But this did not seem to work (resulting in errors) when changing the playground json value to:

let json = "{\"num\": \"0.81\"}"

Is decoding from (and encoding to) a string something that is in the works or I need to implement myself? It wasn't clear from the discussion. Note: It would be nice, akin to Date, to have some control over this (decimalDecodingStrategy/decimalEncodingStrategy)