On Friday, 22 August 2014 at 17:35:20 UTC, Sönke Ludwig wrote:
... why not use exactly the same convention then? =>
`parse!JSONValue`
Would be nice to have a "pluggable" API where you just need to
specify
the type in a factory method to choose the input format. Then
there
could be `parse!BSON`, `parse!YAML`, with the same style as
`parse!(int[])`.
I know this sound a bit like bike-shedding, but the API
shouldn't stand
by itself, but fit into the "big picture", especially as there
will
probably be other parsers (you already named the module
std._data_.json).
That would be nice, but then it should also work together with
std.conv, which basically is exactly this pluggable API. Just
like this it would result in an ambiguity error if both
std.data.json and std.conv are imported at the same time.
Is there a way to make std.conv work properly with JSONValue? I
guess the only theoretical way would be to put something in
JSONValue, but that would result in a slightly ugly cyclic
dependency between parser.d and value.d.
The easiest and cleanest way would be to add a function in
std.data.json:
auto parse(Target, Source)(Source input)
if(is(Target == JSONValue))
{
return ...;
}
The various overloads of `std.conv.parse` already have mutually
exclusive template constraints, they will not collide with our
function.
