RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

Am 22.08.2014 21:48, schrieb Christian Manning:
> 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).
>
> You could check for a decimal point and a 0 at the front (excluding
> possible - sign), either would indicate a double, making the reasonable
> assumption that anything else will fit in a long.

Yes, no decimal point + no exponent would work without overhead to 
detect integers, but that wouldn't solve the proposed automatic 
long->double overflow, which is what I meant. My current idea is to 
default to double and optionally support any of long, BigInt and 
"Decimal" (BigInt+exponent), where integer overflow only works for 
long->BigInt.