RFC: std.json sucessor

[Christian Manning via Digitalmars-d]

> 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.

Ah I see.

I have to say, if you are going to treat integers and floating 
point numbers differently, then you should store them 
differently. long should be used to store integers, double for 
floating point numbers. 64 bit signed integer (long) is a totally 
reasonable limitation for integers, but even that would lose 
precision stored as a double as you are proposing (if I'm 
understanding right). I don't think BigInt needs to be brought 
into this at all really.

In the case of integers met in the parser which are too 
large/small to fit in long, give an error IMO. Such integers 
should be (and are by other libs IIRC) serialised in the form 
"1.234e-123" to force double parsing, perhaps losing precision at 
that stage rather than invisibly inside the library. Size of JSON 
numbers is implementation defined and the whole thing shouldn't 
be degraded in both performance and usability to cover JSON 
serialisers who go beyond common native number types.

Of course, you are free to do whatever you like :)