On Thursday, 24 July 2014 at 15:54:21 UTC, Pavel wrote:
On Thursday, 24 July 2014 at 15:48:32 UTC, Edwin van Leeuwen
wrote:
On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:
On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:
On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:
On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:
Ok, let me start with the sample code:
import std.stdio;
import std.json;
void main() {
scope(failure) writeln("FaILED!!");
string jsonStr = `{ "name": "1", "type": "r" }`;
auto parsed = parseJSON(jsonStr);
string s = parsed["fail"].str;
writeln(s == "");
writeln(s is null);
writeln(s);
}
Running "rdmd app.d" doesn't produce any output.
Can anyone explain such a behavior???
PS: Running dmd v2.065 on Linux x64.
It's a bug in std.json (you should get a segfault, not no
output at all)
It is fixed now and I'm pretty sure it will be in 2.066
std.json has been improved a lot, but I would still
recommend using http://vibed.org/api/vibe.data.json/ instead
perhaps "bug" is too strong a word, but it was a deficiency
that is now corrected. You will get an exception thrown now
and everything should work how you expect.
Maybe. But still it's not the way I expect, any time you
check for non-existing property you must consider exception,
which is very heavy to deal with in such a situation. I'd
rather expect to get null, whenever I try to fetch
non-existing property, and not an exception.
You can turn your json object into an AA object and then use
in to check for existence (I know it is not very intuitive):
JSONValue[string] jsonAA = parsed.object;
if ( "fail" in jsonAA )
s = jsonAA["fail"].str;
That's purely my point, and I don't claim to be right in this
way. It's up to Phobos maintainers to decide how to reprent
JSON parsing results.
Guess what, here's a new snippet:
import std.stdio;
import std.json;
void main() {
scope(failure) writeln("FaILED!!");
string jsonStr = `{ "name": "1", "type": "r" }`;
auto parsed = parseJSON(jsonStr).object;
writeln("fail" in parsed);
}
Output is:
null
WAT?!
Ofcourse, writing like:
writeln(cast(bool)("fail" in parsed));
Produces "false"... but why on earth boolean expression would
output null?
PS: Sorry, for such an emotional boom, I'm so frustrated right
now.
The in operator in d returns a pointer to the element found or
null.
This might be a little confusing at first* but it makes sense for
efficiency reasons. There is often a lot overlap between the work
needed to test for presence and the work needed to fetch an
element.
For types where fetching elements is a significant extra cost you
can always define a `bool contains(K key) { /* ... */ }` so a
user can avoid this cost when appropriate.
*although to be honest it's just a different reading:
`b in c` can be read as "the b in c" or "is b in c?"
