RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

Am 22.08.2014 20:01, schrieb "Marc Schütz" <schuetzm at gmx.net>":
> On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote:
>> Am 22.08.2014 19:27, schrieb "Marc Schütz" <schuetzm at gmx.net>":
>>> On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote:
>>>> Am 22.08.2014 18:31, schrieb Christian Manning:
>>>>> It would be nice to have integers treated separately to doubles. I
>>>>> know
>>>>> it makes the number parsing simpler to just treat everything as
>>>>> double,
>>>>> but still, it could be annoying when you expect an integer type.
>>>>
>>>> That's how I've done it for vibe.data.json, too. For the new
>>>> implementation, I've just used the number parsing routine from
>>>> Andrei's std.jgrandson module. Does anybody have reservations about
>>>> representing integers as "long" instead?
>>>
>>> It should automatically fall back to double on overflow. Maybe even use
>>> BigInt if applicable?
>>
>> I guess BigInt + exponent would be the only lossless way to represent
>> any JSON number. That could then be converted to any desired smaller
>> type as required.
>>
>> But checking for overflow during number parsing would definitely have
>> an impact on parsing speed, as well as using a BigInt of course, so
>> the question is how we want set up the trade off here (or if there is
>> another way that is overhead-free).
>
> As the functions will be templatized anyway, it should include a flags
> parameter. These and possible future extensions can then be selected by
> the user.

I'm actually in the process of converting the "track_location" parameter 
to a flags enum and to add support for an error token, so this would fit 
right in.