std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 29.07.2015 um 18:47 schrieb H. S. Teoh via Digitalmars-d:
> On Wed, Jul 29, 2015 at 03:22:05PM +0000, Don via Digitalmars-d wrote:
>> On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
> [...]
>>> The possible JSON values are:
>>>     string
>>>     number
>>>     object (associative arrays)
>>>     array
>>>     true
>>>     false
>>>     null
>>>
>>> Since these are D builtin types, they can actually be a simple union
>>> of D builtin types.
>>
>> 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.
> [...]
>
> Here's a thought: what about always storing JSON numbers as strings
> (albeit tagged with the "number" type, to differentiate them from actual
> strings in the input), and the user specifies what type to convert it
> to?  The default type can be something handy, like int, but the user has
> the option to ask for size_t, or double, or even BigInt if they want
> (IIRC, the BigInt ctor can initialize an instance from a digit string,
> so if we adopt the convention that non-built-in number-like types can be
> initialized from digit strings, then std.json can simply take a template
> parameter for the output type, and hand it the digit string. This way,
> we can get rid of the std.bigint dependency, except where the user
> actually wants to use BigInt.)
>
>
> T

That means a performance hit, because the string has to be parsed twice 
- once for validation and once for conversion. And it means that for 
non-string inputs the lexer has to allocate for each number. It also 
doesn't know the length of the number in advance, so it can't allocate 
in a generally efficient way.