Subject: [Json] JSON support for BigInt in Chrome/V8

From: Anders Rundgren <[email-masked]>
Date: Sat, 14 Jul 2018 10:39:43 +0200

var small = BigInt("5");
var big = BigInt("5555555555555555555555555500003");
JSON.stringify([big,small]);
VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
      at JSON.stringify (<anonymous>)
      at <anonymous>:1:6

JSON Number serialization has apparently reached a new level (of confusion).

Personally I don't see the problem.  XML did just fine without hard-coded data types.

The JSON type system is basically a relic from JavaScript.  As such it has proved to be quite useful.
However, when you are outside of that scope, the point with the JSON type system gets pretty much zero since you anyway need to map extended types.

Oracle's JSON-B solution which serializes small values as Number and large values as String rather than having a unified serialization based on the underlying data type seems like a pretty broken concept although indeed fully conforming to the JSON specification. "Like the Devil reads the Bible" as we say in Scandinavia :-)

Adding a couple of double quotes is a major problem?  If so, it seems like a way more useful project making quotes optional for keys (named in a specific way), like they already are in JavaScript.

Yeah, and of course adding support for comments.

Anders

---

From: Tim Bray <[email-masked]>
Date: Sat, 14 Jul 2018 15:24:01 -0700

Hmm, this error makes me smile.  Something being a Bigint is a powerful
signal that any such quantity encoded into a JSON number is a likely source
of interoperability problems, as is made quite clear in RFC8259.

Or am I missing something?

On Sat, Jul 14, 2018 at 1:39 AM, Anders Rundgren <
[email-masked]> wrote:

> However, when you are outside of that scope, the point with the JSON type
> system gets pretty much zero since you anyway need to map extended types.
>
> Oracle's JSON-B solution which serializes small values as Number and large
> values as String rather than having a unified serialization based on the
> underlying data type seems like a pretty broken concept although indeed
> fully conforming to the JSON specification. "Like the Devil reads the
> Bible" as we say in Scandinavia :-)
>
> Adding a couple of double quotes is a major problem?  If so, it seems like
> a way more useful project making quotes optional for keys (named in a
> specific way), like they already are in JavaScript.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 15 Jul 2018 06:39:22 +0200

On 2018-07-15 00:24, Tim Bray wrote:
> Hmm, this error makes me smile.  Something being a Bigint is a powerful signal that any such quantity encoded into a JSON number is a likely source of interoperability problems, as is made quite clear in RFC8259.
>

Well, ECMAScript is probably the only language/platform in existence that cannot JSON-serialize all of its intrinsic data types.

The reason for that is not because it is difficult (application developers have done this since ages back), but because the JSON community lacks direction (standards) for dealing with big numbers.

Anders

>
> On Sat, Jul 14, 2018 at 1:39 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>
>     var small = BigInt("5");
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>
>
>
>
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 18 Jul 2018 11:24:33 +0200

On 2018-07-15 00:24, Tim Bray wrote:
> Hmm, this error makes me smile.  

There will be more things to smile about; a bunch of folks are seriously proposing taking JavaScript's recent 'n' notation to JSON {"big":6565656565656565656565656565n}

> Something being a Bigint is a powerful signal that any such quantity  > encoded into a JSON number is a likely source of interoperability problems,
> as is made quite clear in RFC8259.

Well, it is rather treated like a "footnote" by most implementers since there is no RECOMMENDED, MAY, SHOULD or MUST there.

Anders