On Tuesday, 26 August 2014 at 14:06:42 UTC, Sönke Ludwig wrote:
Am 26.08.2014 15:43, schrieb Don:
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
This would probably best added as another (CT) optional
feature. I
think the default should strictly adhere to the JSON
specification,
though.
Yes, it should be optional, but not a compile-time option.
I think it should parse it, and based on a runtime flag, throw
an error
(perhaps an OutOfRange error or something, and use the same
thing for
values that exceed the representable range).
An app may accept these non-standard values under certain
circumstances
and not others. In real-world code, you see a *lot* of these
guys.
Why not a compile time option?
That sounds to me like such an app should simply enable parsing
those values and manually test for NaN at places where it
matters.
For all other (the majority) of applications, encountering
NaN/Infinity will simply mean that there is a bug, so it makes
sense to not accept those at all by default.
Apart from that I don't think that it's a good idea for the
lexer in general to accept non-standard input by default.
Please note, I've been talking about the lexer. I'm choosing my
words very carefully.
Part of the reason these are important, is that NaN or Infinity
generally means some Javascript code just has an uninitialized
variable.
Any other kind of invalid JSON typically means something very
nasty has
happened. It's important to distinguish these.
As far as I understood, JavaScript will output those special
values as null (at least when not using external JSON
libraries).
No. Javascript generates them directly. Naive JS code generates
these guys. That's why they're so important.
But even if not, an uninitialized variable can also be very
nasty, so it's hard to see why that kind of bug should be
silently supported (by default).
I never said it should accepted by default. I said it is a
situation which should be *lexed*. Ideally, by default it should
give a different error from simply 'invalid JSON'. I believe it
should ALWAYS be lexed, even if an error is ultimately generated.
This is the difference: if you get NaN or Infinity, there's
probably a straightforward bug in the Javascript code, but your D
code is fine. Any other kind of JSON parsing error means you've
got a garbage string that isn't JSON at all. They are very
different errors.
It's a diagnostics issue.
