RFC: std.json sucessor

[John Colvin via Digitalmars-d]

On Friday, 22 August 2014 at 20:02:41 UTC, Sönke Ludwig wrote:
> 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.

It might be the right choice anyway (seeing as json/js do 
overflow to double), but fwiw it's still atrocious.

double a = long.max;
assert(iota(1, 1000000).map!(d => (a+d)-a).until!"a != 
0".walkLength == 1024);

Yuk.

Floating point numbers and integers are so completely different 
in behaviour that it's just dishonest to transparently switch 
between the two. This especially the case for overflow from long 
-> double, where by definition you're 10 bits past being able to 
reliably accurately represent the integer in question.