std.data.json formal review

[Walter Bright via Digitalmars-d]

On 7/28/2015 7:07 AM, Atila Neves wrote:
> Start of the two week process, folks.

Thank you very much, Sönke, for taking this on. Thank you, Atila, for taking on 
the thankless job of being review manager.

Just looking at the documentation only, some general notes:

1. Not sure that 'JSON' needs to be embedded in the public names. 
'parseJSONStream' should just be 'parseStream', etc. Name disambiguation, if 
needed, should be ably taken care of by a number of D features for that purpose. 
Additionally, I presume that the stdx.data package implies a number of different 
formats. These formats should all use the same names with as similar as possible 
APIs - this won't work too well if JSON is embedded in the APIs.

2. JSON is a trivial format, http://json.org/. But I count 6 files and 30 names 
in the public API.

3. Stepping back a bit, when I think of parsing JSON data, I think:

     auto ast = inputrange.toJSON();

where toJSON() accepts an input range and produces a container, the ast. The ast 
is just a JSON value. Then, I can just query the ast to see what kind of value 
it is (using overloading), and walk it as necessary. To create output:

     auto r = ast.toChars();  // r is an InputRange of characters
     writeln(r);

So, we'll need:
     toJSON
     toChars
     JSONException

The possible JSON values are:
     string
     number
     object (associative arrays)
     array
     true
     false
     null

Since these are D builtin types, they can actually be a simple union of D 
builtin types.

There is a decision needed about whether toJSON() allocates data or returns 
slices into its inputrange. This can be 'static if' tested by: if inputrange can 
return immutable slices. toChars() can take a compile time argument to determine 
if it is 'pretty' or not.