[swift-evolution] [Accepted] SE-0167: Swift Encoders
iferber at apple.com
Tue May 9 15:05:53 CDT 2017
This is implementation detail that is subject to change, but JSONEncoder and JSONDecoder defer to JSONSerialization to provide the actual serialization to and from JSON.
Internally, numbers are represented in NSNumber instances until you ask for them on decode, so large integers are indeed non-lossy — you can round-trip the values in a 64-bit integer just fine.
If you ask to coerce them as Double values, they will coerce (and lose precision), but that is true today.
Of course, it is not possible to encode values out of Double range as Doubles, since you cannot construct such a Double value.
To wit, any number value encoded via JSONEncoder will always be round-trippable via JSONDecoder provided that you try to decode as the same type as you encoded; this we guarantee.
tl;dr: If you ask for this number as an Int64 or UInt64, you will get the full number without loss of precision.
> On May 9, 2017, at 9:27 AM, Johannes Weiss via swift-evolution <swift-evolution at swift.org> wrote:
> Sorry, I'm very late to the party but have one quick question that I think should be resolved/documented before the patch is landed:
> [9851624185071827, 9851624185071829] as [Double] makes them
> [9851624185071828, 9851624185071828]
> (so two different numbers get both mapped to a third number which sometimes causes problems in the real world )
> The I(nternet)-JSON RFC  states that
> Implementations that generate I-JSON messages cannot assume that
> receiving implementations can process numeric values with greater
> magnitude or precision than provided by those numbers.
> For applications that require the exact interchange of numbers with
> greater magnitude or precision, it is RECOMMENDED to encode them in
> JSON string values.
> I'm not sure if following that recommendation is a good idea but in any case I think it would be worth documenting it. Other encoders sometimes allow you to specify 'numbers as strings' as an option  or outright refuse to encode it.
> Twitter also covers the subject  for its API.
> : https://tools.ietf.org/html/rfc7493#section-2.2
> : https://fasterxml.github.io/jackson-core/javadoc/2.4/com/fasterxml/jackson/core/JsonGenerator.Feature.html#WRITE_NUMBERS_AS_STRINGS
> : https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake
> : https://github.com/nodejs/node/issues/12115
>> On 26 Apr 2017, at 12:10 am, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>> The review of SE-0167 "SE-0167: Swift Encoders” ran from April 6...12, 2017. The proposal is accepted. Thanks to everyone who participated in the review!
>> - Doug
>> Review Manager
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution