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.

Reply via email to