RFC: std.json sucessor

[Don via Digitalmars-d]

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.