std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 14.08.2015 um 02:26 schrieb Walter Bright:
> On 8/13/2015 3:51 AM, Sönke Ludwig wrote:
>> These were, AFAICS, the only major open issues (a decision for an
>> opt() variant
>> would be nice, but fortunately that's not a fundamental decision in
>> any way).
>
> 1. What about the issue of having the API be a composable range interface?
>
> http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html
>
> I.e. the input range should be the FIRST argument, not the last.

Hm, it *is* the first function argument, just the last template argument.

>
> 2. Why are integers acceptable as lexer input? The spec specifies Unicode.

In this case, the lexer will perform on-the-fly UTF validation of the 
input. It can do so more efficiently than first validating the input 
using a wrapper range, because it has to check the value of most 
incoming code units anyway.

>
> 3. Why are there 4 functions that do the same thing?
>
> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator.html
>
> After all, there already is a
> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.html
>

There are two classes of functions that are not covered by 
GeneratorOptions: writing to a stream or returning a string. But you are 
right that pretty printing should be controlled by GeneratorOptions. 
I'll fix that. The suggestion to use pretty printing by default also 
sounds good.