std.data.json formal review

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 29 September 2015 at 11:06:03 UTC, Marc Schütz wrote:
> On Monday, 28 September 2015 at 07:02:35 UTC, Marco Leise wrote:
>> Am Tue, 18 Aug 2015 09:05:32 +0000
>> schrieb "Marc Schütz" <schuetzm at gmx.net>:
>>
>>> Or, as above, leave it to the end user and provide a `to(T)` 
>>> method that can support built-in types and `BigInt` alike.
>>
>> You mean the user should write a JSON number parsing routine
>> on their own? Then which part is responsible for validation of
>> JSON contraints? If it is the to!(T) function, then it is
>> code duplication with chances of getting something wrong,
>> if it is the JSON parser, then the number is parsed twice.
>> Besides, there is a lot of code to be shared for every T.
>
> No, the JSON type should just store the raw unparsed token and 
> implement:
>
>     struct JSON {
>         T to(T) if(isNumeric!T && is(typeof(T("")))) {
>             return T(this.raw);
>         }
>     }
>
> The end user can then call:
>
>     auto value = json.to!BigInt;



I was just speaking to Sonke about another aspect of this.  It's 
not just numbers where this might be the case - dates are also 
often in a weird format (because the data comes from some ancient 
mainframe, for example).  And similarly for enums where the field 
is a string but actually ought to fit in a fixed set of 
categories.

I forgot the original context to this long thread, so hopefully 
this point is relevant.  It's more relevant for the layer that 
will go on top where you want to be able to parse a json array or 
object as a D array/associative array of structs, as you can do 
in vibe.d currently.  But maybe needs to be considered in lower 
level - I forget at this point.