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" <[email protected]>:
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.
