std.data.json formal review

[Rikki Cattermole via Digitalmars-d]

On 29/07/2015 4:41 a.m., Sönke Ludwig wrote:
> Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
>> On 29/07/2015 2:07 a.m., Atila Neves wrote:
>>> Start of the two week process, folks.
>>>
>>> Code: https://github.com/s-ludwig/std_data_json
>>> Docs: http://s-ludwig.github.io/std_data_json/
>>>
>>> Atila
>>
>> Right now, my view is no.
>> Unless there is some sort of proof that it will work with allocators.
>>
>> I have used the code from vibe.d days so its not an issue of how well it
>> works nor nit picky. Just can I pass it an allocator (optionally) and
>> have it use that for all memory usage?
>>
>> After all, I really would rather be able to deallocate all memory
>> allocated during a request then you know, rely on the GC.
>
> If you pass a string or byte array as input, then there will be no
> allocations at all (the interface is @nogc).
>
> For other cases it supports custom allocation through an appender
> factory [1][2], since there is no standard allocator interface, yet. But
> since that's the only place where memory is allocated (apart from lower
> level code, such as BigInt), as soon as Appender supports custom
> allocators, or you write your own appender, the JSON parser will, too.
>
> Only if you use the DOM parser, there will be some inevitable GC
> allocations, because the DOM representation uses dynamic and associative
> arrays.
>
> 1:
> https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/lexer.d#L66
>
> 2:
> https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/parser.d#L286

It was after 3am when I did my initial look. But I saw the appender 
usage. I'm ok with this.
The DOM parser on the other hand.. ugh this is where we do need 
IAllocator being used. Although by the sounds of it, we would need a map 
collection which supports allocators before it can be done.