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.
