std.data.json formal review

[Walter Bright via Digitalmars-d]

On 7/28/2015 3:37 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
> Ideally, I'd say hook it up to std.conv.to for maximum flexibility. Then
> you can just use to() to convert between a JSON container and the value
> that it represents (assuming the types are compatible).

Well, I wouldn't want std.conv to be importing std.json.


> OTOH, some people might want the option of parser-driven data processing
> instead (e.g. the JSON data is very large and we don't want to store the
> whole thing in memory at once).

That is a good point.


> I'm not sure what a good API for that would be, though.

Probably simply returning an InputRange of JSON values.


>> To create output:
>>
>>      auto r = ast.toChars();  // r is an InputRange of characters
>>      writeln(r);
>>
>> So, we'll need:
>>      toJSON
>>      toChars
>
> Shouldn't it just be toString()?

No. toString() returns a string, which has to be allocated. toChars() (an 
upcoming convention) would return an InputRange instead, side-stepping allocation.


> Whether or not toJSON() allocates *data*, it will have to allocate
> container nodes of some sort. At the minimum, it will need to use AA's,
> so it cannot be @nogc.

That's right. At some point the API will need to add a parameter for Andrei's 
allocator system.