RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

Am 22.08.2014 19:57, schrieb "Marc Schütz" <schuetzm at gmx.net>":
> 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!()?