On Wednesday, 29 July 2015 at 15:22:06 UTC, Don wrote:
On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[snip]
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.
Actually JSON is defined as subset of EMCASCript-262 spec hence
it may not ciontain anything other 64-bit5 IEEE-754 numbers
period.
See:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type
Anything else is e-hm an "extension" (or simply put - violation
of spec), I've certainly seen 64-bit integers in the wild - how
often true big ints are found out there?
If no one can present some run of the mill REST JSON API breaking
the rules I'd suggest demoting BigInt handling to optional
feature.
