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" <schue...@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.
