RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

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.

>
> 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). 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).