Am 23.08.2014 20:31, schrieb "Marc Schütz" <schue...@gmx.net>":
On Saturday, 23 August 2014 at 17:32:01 UTC, Sönke Ludwig wrote:
Am 23.08.2014 19:25, schrieb "Marc Schütz" <schue...@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" <schue...@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" <schue...@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".

Probably, but then to!() is inconsistent with parse!(). Usually they are both the same apart from how the tail of the input string is handled.

Reply via email to