RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

Am 25.08.2014 16:04, schrieb Sönke Ludwig:
> Am 25.08.2014 15:07, schrieb Don:
>> On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
>>> Following up on the recent "std.jgrandson" thread [1], I've picked up
>>> the work (a lot earlier than anticipated) and finished a first version
>>> of a loose blend of said std.jgrandson, vibe.data.json and some
>>> changes that I had planned for vibe.data.json for a while. I'm quite
>>> pleased by the results so far, although without a serialization
>>> framework it still misses a very important building block.
>>>
>>> Code: https://github.com/s-ludwig/std_data_json
>>> Docs: http://s-ludwig.github.io/std_data_json/
>>> DUB: http://code.dlang.org/packages/std_data_json
>>>
>>> The new code contains:
>>>  - Lazy lexer in the form of a token input range (using slices of the
>>>    input if possible)
>>>  - Lazy streaming parser (StAX style) in the form of a node input range
>>>  - Eager DOM style parser returning a JSONValue
>>>  - Range based JSON string generator taking either a token range, a
>>>    node range, or a JSONValue
>>>  - Opt-out location tracking (line/column) for tokens, nodes and values
>>>  - No opDispatch() for JSONValue - this has shown to do more harm than
>>>    good in vibe.data.json
>>>
>>> The DOM style JSONValue type is based on std.variant.Algebraic. This
>>> currently has a few usability issues that can be solved by
>>> upgrading/fixing Algebraic:
>>>
>>>  - Operator overloading only works sporadically
>>>  - No "tag" enum is supported, so that switch()ing on the type of a
>>>    value doesn't work and an if-else cascade is required
>>>  - Operations and conversions between different Algebraic types is not
>>>    conveniently supported, which gets important when other similar
>>>    formats get supported (e.g. BSON)
>>>
>>> Assuming that those points are solved, I'd like to get some early
>>> feedback before going for an official review. One open issue is how to
>>> handle unescaping of string literals. Currently it always unescapes
>>> immediately, which is more efficient for general input ranges when the
>>> unescaped result is needed, but less efficient for string inputs when
>>> the unescaped result is not needed. Maybe a flag could be used to
>>> conditionally switch behavior depending on the input range type.
>>>
>>> Destroy away! ;)
>>>
>>> [1]: http://forum.dlang.org/thread/lrknjl$co7$1@digitalmars.com
>>
>>
>> One missing feature (which is also missing from the existing std.json)
>> is support for NaN and Infinity as JSON values. Although they are not
>> part of the formal JSON spec (which is a ridiculous omission, the
>> argument given for excluding them is fallacious), they do get generated
>> if you use Javascript's toString to create the JSON. Many JSON libraries
>> (eg Google's) also generate them, so they are frequently encountered in
>> practice. So a JSON parser should at least be able to lex them.
>>
>> 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.

http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/LexOptions.specialFloatLiterals.html

>
>>
>> You should also put tests in for what happens when you pass NaN or
>> infinity to toJSON. It shouldn't silently generate invalid JSON.
>
> Good point. The current solution to just use formattedWrite("%.16g") is
> also not ideal.

By default, floating-point special values are now output as 'null', 
according to the ECMA-script standard. Optionally, they will be emitted 
as 'NaN' and 'Infinity':

http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.specialFloatLiterals.html