RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

Am 26.08.2014 16:40, schrieb Don:
> 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.

I've been talking about the lexer, too. Sorry for the confusing use of 
the term "parsing" (after all, the lexer is also a parser, but anyway).

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

JSON.stringify(0/0) == "null"

Holds for all browsers that I've tested.

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

The error will be more like "filename(line:column): Invalid token" - 
possibly the text following the line/column could also be displayed. 
Wouldn't that be sufficient?