std.data.json formal review

[Dmitry Olshansky via Digitalmars-d]

On 03-Aug-2015 10:56, Sönke Ludwig wrote:
> Am 02.08.2015 um 19:14 schrieb Dmitry Olshansky:
>>
>> 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.
>>
>>
>
> This is not true. Quoting from ECMA-404:
>
>> JSON is a text format that facilitates structured data interchange
>> between all programming languages. JSON
>> is syntax of braces, brackets, colons, and commas that is useful in
>> many contexts, profiles, and applications.
>> JSON  was  inspired  by  the  object  literals  of  JavaScript  aka
>> ECMAScript  as  defined  in  the  ECMAScript
>> Language   Specification,   third   Edition   [1].
>> It  does  not  attempt  to  impose  ECMAScript’s  internal  data
>> representations on other programming languages. Instead, it shares a
>> small subset of ECMAScript’s textual
>> representations with all other programming languages.
>> JSON  is  agnostic  about  numbers.  In  any  programming  language,
>> there  can  be  a  variety  of  number  types  of
>> various capacities and complements, fixed or floating, binary or
>> decimal. That can make interchange between
>> different  programming  languages  difficult.  JSON  instead  offers
>> only  the  representation  of  numbers  that
>> humans use: a sequence  of digits.  All programming languages know
>> how to make sense of digit sequences
>> even if they disagree on internal representations. That is enough to
>> allow interchange.

Hm about 5 solid pages and indeed it leaves everything unspecified for 
extensibility so I stand corrected.
Still I'm more inclined to put my trust in RFCs, such as the new one:
http://www.ietf.org/rfc/rfc7159.txt

Which states:

    This specification allows implementations to set limits on the range
    and precision of numbers accepted.  Since software that implements
    IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
    generally available and widely used, good interoperability can be
    achieved by implementations that expect no more precision or range
    than these provide, in the sense that implementations will
    approximate JSON numbers within the expected precision.  A JSON
    number such as 1E400 or 3.141592653589793238462643383279 may indicate
    potential interoperability problems, since it suggests that the
    software that created it expects receiving software to have greater
    capabilities for numeric magnitude and precision than is widely
    available.

    Note that when such software is used, numbers that are integers and
    are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
    sense that implementations will agree exactly on their numeric
    values.

And it implies setting limits on everything:

9.  Parsers

    A JSON parser transforms a JSON text into another representation.  A
    JSON parser MUST accept all texts that conform to the JSON grammar.
    A JSON parser MAY accept non-JSON forms or extensions.

    An implementation may set limits on the size of texts that it
    accepts.  An implementation may set limits on the maximum depth of
    nesting.  An implementation may set limits on the range and precision
    of numbers.  An implementation may set limits on the length and
    character contents of strings.


Now back to our land let's look at say rapidJSON.

It MAY seem to handle big integers:
https://github.com/miloyip/rapidjson/blob/master/include/rapidjson/internal/biginteger.h

But it's used only to parse doubles:
https://github.com/miloyip/rapidjson/pull/137

Anyhow the API says it all - only integers up to 64bit and doubles:

http://rapidjson.org/md_doc_sax.html#Handler

Pretty much what I expect by default.
And plz-plz don't hardcode BitInteger in JSON parser, it's slow plus it 
causes epic code bloat as Don already pointed out.

-- 
Dmitry Olshansky