std.data.json formal review

[Walter Bright via Digitalmars-d]

On 8/16/2015 5:34 AM, Sönke Ludwig wrote:
> Am 16.08.2015 um 02:50 schrieb Walter Bright:
>>      if (isInputRange!R && is(Unqual!(ElementEncodingType!R) == char))
>>
>> I'm not a fan of more names for trivia, the deluge of names has its own
>> costs.
>
> Good, I'll use `if (isInputRange!R && (isSomeChar!(ElementEncodingType!R) ||
> isIntegral!(ElementEncodingType!R))`. It's just used in number of places and
> quite a bit more verbose (twice as long) and I guess a large number of
> algorithms in Phobos accept char ranges, so that may actually warrant a name in
> this case.

Except that there is no reason to support wchar, dchar, int, ubyte, or anything 
other than char. The idea is not to support something just because you can, but 
there should be an identifiable, real use case for it first. Has anyone ever 
seen Json data as ulongs? I haven't either.


>> The json parser will work fine without doing any validation at all. I've
>> been implementing string handling code in Phobos with the idea of doing
>> validation only if the algorithm requires it, and only for those parts
>> that require it.
>
> Yes, and it won't do that if a char range is passed in. If the integral range
> path gets removed there are basically two possibilities left, perform the
> validation up-front (slower), or risk UTF exceptions in unrelated parts of the
> code base. I don't see why we shouldn't take the opportunity for a full and fast
> validation here. But I'll relay this to Andrei, it was his idea originally.

That argument could be used to justify validation in every single algorithm that 
deals with strings.


>>>> 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.
>>
>> Back to the previous point, that means that every algorithm in Phobos
>> should have two versions, one that returns a range and the other a
>> string? All these variations will result in a combinatorical explosion.
>
> This may be a factor of two, but not a combinatorial explosion.

We're already up to validate or not, to string or not, i.e. 4 combinations.


>> The other problem, of course, is that returning a string means the
>> algorithm has to decide how to allocate that string. As much as
>> possible, algorithms should not be making allocation decisions.
>
> Granted, the fact that format() and to!() support input ranges (I didn't notice
> that until now) makes the issue less important. But without those, it would
> basically mean that almost all places that generate JSON strings would have to
> import std.array and append .array. Nothing particularly bad if viewed in
> isolation, but makes the language appear a lot less clean/more verbose if it
> occurs often. It's also a stepping stone for language newcomers.

This has been argued before, and the problem is it applies to EVERY algorithm in 
Phobos, and winds up with a doubling of the number of functions to deal with it. 
I do not view this as clean.

D is going to be built around ranges as a fundamental way of coding. Users will 
need to learn something about them. Appending .array is not a big hill to climb.


> There are output range and allocation based float->string conversions available,
> but no input range based one. But well, using an internal buffer together with
> formattedWrite would probably be a viable workaround...

I plan to fix that, so using a workaround in the meantime is appropriate.