Am 22.08.2014 20:01, schrieb "Marc Schütz" <schue...@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" <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).
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.
