RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

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