Thanx T.J.

With your suggestion there are now not less than FIVE proposals on the table for dealing with BigInt JSON serialization:

*RFC8259: 123456789123456789123456789
ES6 enhanced: 123456789123456789123456789n
Typed: "/BigInt(123456789123456789123456789)/"
*Adaptive: "123456789123456789123456789" respectively 123456789
*Conservative: "123456789123456789123456789"

Maybe Carsten Bormann after all is right, it is time to jump the JSON ship!

Before the industry takes the leap to CBOR, I personally stick to the conservative path because it appears to be compatible ("usable" is maybe a better word) with just about everything out there.

I wouldn't completely ignore the fact that XML did just fine without any explicit type information at all.  OpenAPI addresses this for Date to take an example.  They are though still grappling with BigInt :-)

Cheers,
Anders

* Denotes implemented/in use

On 2018-07-26 18:51, T.J. Crowder wrote:
> Not having JSON support for BigInt is a big problem. But the fact exists that JSON does not cover everything. It doesn't cover Dates, Maps, Sets, Symbols...
> 
> Until/unless the successor to JSON (whatever it may be) is created and adopted, a process that will take years, let's take a pragmatic approach similar to the pragmatic approach taken in relation to Dates: Abuse a string.
> 
> ```js
> BigInt.prototype.toJSON = function() {
>      return `/BigInt(${this.toString()})/`;
> };
> ```
> 
> Then this:
> 
> ```js
> console.log(JSON.stringify({n:10n}));
> ```
> 
> outputs
> 
> ```
> {"n":"/BigInt(10)/"}
> ```
> 
> Do I like it? Not even a little bit. But as a pragmatic way forward, providing `toJSON` on BigInt's prototype and having it produce something along these lines seems like Better Than Nothing™. Date's `toJSON` produces a string in a readily-recognized format, after all. I'd also suggest `BigInt.fromJSON` which validated and parsed the string in that format.
> 
> This would put us where Dates are now, but without competing standards for them (ISO string vs.` /Date(epochval)/`).
> 
> -- T.J. Crowder
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

Thanx T.J.

With your suggestion there are now not less than FIVE proposals on the table for dealing with BigInt JSON serialization:

- \* RFC8259: `123456789123456789123456789`
- ES6 enhanced: `123456789123456789123456789n`
- Typed: `"/BigInt(123456789123456789123456789)/"`
- \* Adaptive: `"123456789123456789123456789"` respectively `123456789`
- \* Conservative: `"123456789123456789123456789"`

Maybe Carsten Bormann after all is right, it is time to jump the JSON ship!

Before the industry takes the leap to CBOR, I personally stick to the conservative path because it appears to be compatible ("usable" is maybe a better word) with just about everything out there.

I wouldn't completely ignore the fact that XML did just fine without any explicit type information at all.  OpenAPI addresses this for Date to take an example.  They are though still grappling with BigInt :-)

Cheers,
Anders

\* Denotes implemented/in use

Thanx T.J.

With your suggestion there are now not less than FIVE proposals on the table for dealing with BigInt JSON serialization:

- \* RFC8259: 123456789123456789123456789
- ES6 enhanced: 123456789123456789123456789n
- Typed: "/BigInt(123456789123456789123456789)/"
- \* Adaptive: "123456789123456789123456789" respectively 123456789
- \* Conservative: "123456789123456789123456789"

Maybe Carsten Bormann after all is right, it is time to jump the JSON ship!

Before the industry takes the leap to CBOR, I personally stick to the conservative path because it appears to be compatible ("usable" is maybe a better word) with just about everything out there.

I wouldn't completely ignore the fact that XML did just fine without any explicit type information at all.  OpenAPI addresses this for Date to take an example.  They are though still grappling with BigInt :-)

Cheers,
Anders

\* Denotes implemented/in use