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 toCharsShouldn'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.
