std.data.json formal review

[Dmitry Olshansky via Digitalmars-d]

On Wednesday, 29 July 2015 at 15:22:06 UTC, Don wrote:
> On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[snip]

> Related to this: it should not be importing std.bigint. Note 
> that if std.bigint were fully implemented, it would be very 
> heavyweight (optimal multiplication of enormous integers 
> involves fast fourier transforms and all kinds of odd stuff, 
> that's really bizarre to pull in if you're just parsing a 
> trivial little JSON config file).
>
> Although it is possible for JSON to contain numbers which are 
> larger than can fit into long or ulong, it's an abnormal case. 
> Many apps (probably, almost all) will want to reject such 
> numbers immediately. BigInt should be opt-in.
>
> And, it is also possible to have floating point numbers that 
> are not representable in double or real. BigInt doesn't solve 
> that case.
>
> It might be adequate to simply present it as a raw number (an 
> unconverted string) if it isn't a built-in type. Parse it for 
> validity, but don't actually convert it.

Actually JSON is defined as subset of EMCASCript-262 spec hence 
it may not ciontain anything other 64-bit5 IEEE-754 numbers 
period.
See:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type

Anything else is e-hm an "extension" (or simply put - violation 
of spec), I've certainly seen 64-bit integers in the wild - how 
often true big ints are found out there?

If no one can present some run of the mill REST JSON API breaking 
the rules I'd suggest demoting BigInt handling to optional 
feature.