Am 22.08.2014 19:57, schrieb "Marc Schütz" <[email protected]>":
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.
Okay, for parse that may work, but what about to!()?
