std.json API improvement - Request for code review

[Sean Kelly]

Robert Jacques Wrote:
> 
> Hi Brain,
> This really belongs on the phobos mailing list as JSON isn't ready for  
> public consumption yet (as far as I know). I would suspect that it even  
> has a decent chance of being dropped in favor of serialization + variant.  
> The implementation has several bugs. First, it doesn't parse Unicode  
> escape sequences correctly (e.g. \u0026). Second, JSON has no integer  
> type. Third, the serializer with certain JSON value inputs will write a  
> JSON file that can not be read by the parser. It's also missing some key  
> features, like output range and human readable output support. The design  
> is very C-ish as opposed to D-ish: its composed of a bunch of free  
> functions / types all containing JSON in their name. (i.e. parseJSON).  
> These should all be encapsulated as member functions.
> 
> Getting more to the API itself, the reading of a JSON value is a use case  
> that just isn't considered currently. Consider:
> 
> // It's relatively simple to write to a JSON value
> json["vector"]["x"] = 42.8;
> 
> // But reading it...
> real x;
> if(json["vector"]["x"].type == JSON_TYPE.INTEGER) {
>      x = json["vector"]["x"].integer;
> } else if(json["vector"]["x"].type == JSON_TYPE.FLOAT) {
>      x = json["vector"]["x"].floating;
> } else {
>      enforceEx!(JSONException)(false);
> }
> 
> By contrast, this is the API on my personal JSON library:
> json.vector.x = 42.8;
> auto x = json.vector.x.number;

Could all this sit atop a SAX-style API?  I'm not likely to ever use an API that requires memory allocation for parsing or writing data.