std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 14.08.2015 um 10:17 schrieb Walter Bright:
> On 8/13/2015 11:52 PM, Sönke Ludwig wrote:
>> 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.
>
> Ok, my mistake. I didn't look at the others.
>
> I don't know what 'isStringInputRange' is. Whatever it is, it should be
> a 'range of char'.

I'll rename it to isCharInputRange. We don't have something like that in 
Phobos, right?

>>> 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.
>
> There is no reason to validate UTF-8 input. The only place where
> non-ASCII code units can even legally appear is inside strings, and
> there they can just be copied verbatim while looking for the end of the
> string.

The idea is to assume that any char based input is already valid UTF (as 
D defines it), while integer based input comes from an unverified 
source, so that it still has to be validated before being cast/copied 
into a 'string'. I think this is a sensible approach, both semantically 
and performance-wise.

>
>
>>> 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.
>
> Why do both? Always return an input range. If the user wants a string,
> he can pipe the input range to a string generator, such as .array

Convenience for one. The lack of number to input range conversion 
functions is another concern. I'm not really keen to implement an input 
range style floating-point to string conversion routine just for this 
module.

Finally, I'm a little worried about performance. The output range based 
approach can keep a lot of state implicitly using the program counter 
register. But an input range would explicitly have to keep track of the 
current JSON element, as well as the current character/state within that 
element (and possibly one level deeper, for example for escape 
sequences). This means that it will require either multiple branches or 
indirection for each popFront().