<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Johannes,<div class=""><br class=""></div><div class="">This is implementation detail that is subject to change, but <font face="Menlo" class="">JSONEncoder</font> and <font face="Menlo" class="">JSONDecoder</font> defer to <font face="Menlo" class="">JSONSerialization</font> to provide the actual serialization to and from JSON.</div><div class="">Internally, numbers are represented in <font face="Menlo" class="">NSNumber</font> 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.</div><div class=""><br class=""></div><div class="">If you ask to coerce them as <font face="Menlo" class="">Double</font> values, they will coerce (and lose precision), but that is true today.</div><div class="">Of course, it is not possible to <i class="">encode</i> values out of <font face="Menlo" class="">Double</font> range as <font face="Menlo" class="">Double</font>s, since you cannot construct such a <font face="Menlo" class="">Double</font> value.</div><div class=""><br class=""></div><div class="">To wit, any number value encoded via <font face="Menlo" class="">JSONEncoder</font> will always be round-trippable via <font face="Menlo" class="">JSONDecoder</font> provided that you try to decode as the same type as you encoded; this we guarantee.</div><div class=""><br class=""></div><div class=""><b class="">tl;dr</b>: If you ask for this number as an <font face="Menlo" class="">Int64</font> or <font face="Menlo" class="">UInt64</font>, you will get the full number without loss of precision.</div><div class=""><br class=""></div><div class="">— Itai</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 9, 2017, at 9:27 AM, Johannes Weiss via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">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:<br class=""><br class="">What do we do with integers outside the range [-(2**53)+1, (2**53)-1])? Those are which are the integers that are precisely representable by doubles (IEEE 754-2008 binary64 (double precision). And the problem is that at least JavaScript treats all numbers as doubles, which leads to this problem:<br class=""><br class="">[9851624185071827, 9851624185071829] as [Double] makes them<br class="">[9851624185071828, 9851624185071828]<br class=""><br class="">(so two different numbers get both mapped to a third number which sometimes causes problems in the real world [4])<br class=""><br class=""><br class="">The I(nternet)-JSON RFC [1] states that<br class=""><br class=""> Implementations that generate I-JSON messages cannot assume that<br class=""> receiving implementations can process numeric values with greater<br class=""> magnitude or precision than provided by those numbers.<br class=""><br class="">Now since Swift isn't JavaScript we fortunately don't store all numbers as doubles so I'm sure a roundtrip of the number 9851624185071827 (which is outside that range) will just work. Nevertheless the RFC [1] says<br class=""><br class=""> For applications that require the exact interchange of numbers with<br class=""> greater magnitude or precision, it is RECOMMENDED to encode them in<br class=""> JSON string values.<br class=""><br class="">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 [2] or outright refuse to encode it.<br class=""><br class="">Twitter also covers the subject [3] for its API.<br class=""><br class="">-- <br class=""> Johannes<br class=""><br class="">[1]: <a href="https://tools.ietf.org/html/rfc7493#section-2.2" class="">https://tools.ietf.org/html/rfc7493#section-2.2</a><br class="">[2]: <a href="https://fasterxml.github.io/jackson-core/javadoc/2.4/com/fasterxml/jackson/core/JsonGenerator.Feature.html#WRITE_NUMBERS_AS_STRINGS" class="">https://fasterxml.github.io/jackson-core/javadoc/2.4/com/fasterxml/jackson/core/JsonGenerator.Feature.html#WRITE_NUMBERS_AS_STRINGS</a><br class="">[3]: <a href="https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake" class="">https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake</a><br class="">[4]: <a href="https://github.com/nodejs/node/issues/12115" class="">https://github.com/nodejs/node/issues/12115</a><br class=""><br class=""><blockquote type="cite" class="">On 26 Apr 2017, at 12:10 am, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md</a><br class=""><br class="">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!<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Review Manager<br class=""><br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>