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