Am 29.07.2015 um 18:47 schrieb H. S. Teoh via Digitalmars-d:
On Wed, Jul 29, 2015 at 03:22:05PM +0000, Don via Digitalmars-d wrote:
On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[...]
The possible JSON values are:
string
number
object (associative arrays)
array
true
false
null
Since these are D builtin types, they can actually be a simple union
of D builtin types.
Related to this: it should not be importing std.bigint. Note that if
std.bigint were fully implemented, it would be very heavyweight
(optimal multiplication of enormous integers involves fast fourier
transforms and all kinds of odd stuff, that's really bizarre to pull
in if you're just parsing a trivial little JSON config file).
Although it is possible for JSON to contain numbers which are larger
than can fit into long or ulong, it's an abnormal case. Many apps
(probably, almost all) will want to reject such numbers immediately.
BigInt should be opt-in.
And, it is also possible to have floating point numbers that are not
representable in double or real. BigInt doesn't solve that case.
It might be adequate to simply present it as a raw number (an
unconverted string) if it isn't a built-in type. Parse it for
validity, but don't actually convert it.
[...]
Here's a thought: what about always storing JSON numbers as strings
(albeit tagged with the "number" type, to differentiate them from actual
strings in the input), and the user specifies what type to convert it
to? The default type can be something handy, like int, but the user has
the option to ask for size_t, or double, or even BigInt if they want
(IIRC, the BigInt ctor can initialize an instance from a digit string,
so if we adopt the convention that non-built-in number-like types can be
initialized from digit strings, then std.json can simply take a template
parameter for the output type, and hand it the digit string. This way,
we can get rid of the std.bigint dependency, except where the user
actually wants to use BigInt.)
T
That means a performance hit, because the string has to be parsed twice
- once for validation and once for conversion. And it means that for
non-string inputs the lexer has to allocate for each number. It also
doesn't know the length of the number in advance, so it can't allocate
in a generally efficient way.
