RFC: std.json sucessor

[via Digitalmars-d]

On Saturday, 23 August 2014 at 17:32:01 UTC, Sönke Ludwig wrote:
> Am 23.08.2014 19:25, schrieb "Marc Schütz" <schuetzm at gmx.net>":
>> On Saturday, 23 August 2014 at 16:49:23 UTC, Sönke Ludwig 
>> wrote:
>>> Am 22.08.2014 21:00, schrieb "Marc Schütz" 
>>> <schuetzm at gmx.net>":
>>>> On Friday, 22 August 2014 at 18:08:34 UTC, Sönke Ludwig 
>>>> wrote:
>>>>> Am 22.08.2014 19:57, schrieb "Marc Schütz" 
>>>>> <schuetzm at gmx.net>":
>>>>>> 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!()?
>>>>
>>>> What's the problem with to!()?
>>>
>>> to!() definitely doesn't have a template constraint that 
>>> excludes
>>> JSONValue. Instead, it will convert any struct type that 
>>> doesn't
>>> define toString() to a D-like representation.
>>
>> For converting a JSONValue to a different type, JSONValue can 
>> implement
>> `opCast`, which is the regular interface that std.conv.to uses 
>> if it's
>> available.
>>
>> For converting something _to_ a JSONValue, std.conv.to will 
>> simply
>> create an instance of it by calling the constructor.
>
> That would just introduce the said dependency cycle between 
> JSONValue, the parser and the lexer. Possible, but not 
> particularly pretty. Also, using the JSONValue constructor to 
> parse an input string would contradict the intuitive behavior 
> to just store the string value.

That's what I expect it to do anyway. For parsing, there are 
already other functions. "mystring".to!JSONValue should just wrap 
"mystring".