RFC: std.json sucessor

[via Digitalmars-d]

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.