Bug 15331 – std.json objects should implement opIn_r

How do I determine whether a JSON object contains a value with a particular key? --- JSONValue v; bool contained; try { v = jsonObj["foo"]; contained = true; } catch (JSONException) { } if (contained) { // do stuff with v } --- Alternatively: --- JSONValue v; bool contained; foreach (string k, v2; jsonObj) { if (k == "foo") { v = v2; contained = true; break; } } if (contained) { // do stuff with v } --- There should be a convenient method to check whether an object contains a key. Obligatory usecase: I'm consuming a JSON API schema to auto-generate an API client for AWS. The schema omits the "input" key if no input is necessary and the "output" key if no output is emitted from the API method.

The opIn_r operator is supported . However another issue should be opened to ask for it to be documented. --- void main(string[] args) { import std.json; JSONValue v = parseJSON("{}"); assert("whatever" !in v); } ---

Next time, please open the new bug before resolving the old one. There's a real problem, and it's not resolved. By creating the new bug first, you can also provide a link to it in the update (like I just did in the "see also" area, and also here in the comments: https://issues.dlang.org/show_bug.cgi?id=15336).

(In reply to Chris Wright from comment #2) > Next time, please open the new bug before resolving the old one. There's a > real problem, and it's not resolved. By creating the new bug first, you can > also provide a link to it in the update (like I just did in the "see also" > area, and also here in the comments: > https://issues.dlang.org/show_bug.cgi?id=15336). No I wont. It's rather up to you, "next time" to take a moment to ask for a clarification either on dlang.learn or even on stack overflow before opening an issue for something that's clearly not one.Always ask before. I always do that. For example here: http://forum.dlang.org/thread/[email protected] I saved the time lost to open a ticket for something that would finish has closed as duplicate.

> No I wont. If you're leaving it to the other person to file the new bug, you could perhaps leave it to them to resolve the issue as invalid. There's far less chance of a real problem getting lost that way. > It's rather up to you, "next time" to take a moment to ask for a clarification First, I'm choosing to spend my time to write up a bug report to improve D. If you are interested in the success of D, that goal would be poorly served by adding roadblocks to others attempting to improve it -- unless filtering out erroneous bugs has already proven onerous. Has it? If so, I'll gladly volunteer a couple hours a week toward verifying and reproducing bugs so that others who are less attached to D can do less legwork up front. Second, you're asking me to take hours of wall time, not a moment. It means I have to make a newsgroup post, which is exactly as much work as filing a bug, then remember to go back to the newsgroup after a few hours, then, if nobody's responded, file a bug. That remembering to file a bug part is nontrivial; it means I'll fail to report a decent fraction of issues I identify. (And if someone responded on the newsgroup after I submitted an issue, you would likely still be snippy at me, leaving me with a dilemma about how long to wait between asking about a problem and filing the bug.) Third, the main thrust of your newsgroup argument was that you found that an issue had already been reported. I can very easily search bugzilla for the string "json" and browse through the bugs that have already been reported. (And I did, because it's the right thing to do.) Your example was for something that's somewhat harder to search for. So your example was poor. Fourth, I frequently see Andrei and Walter telling people to file bugs for issues rather than reporting them to the newsgroup. I'm going with their suggestions rather than yours.

>(In reply to Chris Wright from comment #4) > > No I wont. > > If you're leaving it to the other person to file the new bug, you could > perhaps leave it to them to resolve the issue as invalid. There's far less > chance of a real problem getting lost that way. I knew what i was doing when closing. You know why ? because of this: http://forum.dlang.org/thread/[email protected] > > > It's rather up to you, "next time" to take a moment to ask for a clarification > > First, I'm choosing to spend my time to write up a bug report to improve D. > If you are interested in the success of D, that goal would be poorly served > by adding roadblocks to others attempting to improve it -- unless filtering > out erroneous bugs has already proven onerous. Has it? If so, I'll gladly > volunteer a couple hours a week toward verifying and reproducing bugs so > that others who are less attached to D can do less legwork up front. You see a roadblock while I give the opportunity to improve yourself. > Second, you're asking me to take hours of wall time, not a moment. It means > I have to make a newsgroup post, which is exactly as much work as filing a > bug, then remember to go back to the newsgroup after a few hours, then, if > nobody's responded, file a bug. That remembering to file a bug part is > nontrivial; it means I'll fail to report a decent fraction of issues I > identify. (And if someone responded on the newsgroup after I submitted an > issue, you would likely still be snippy at me, leaving me with a dilemma > about how long to wait between asking about a problem and filing the bug.) By experience I know it's fast, answers come fast in dlang.lean. By experience I also know that the simple fact to formulate a problem better (so that everybody can understand it) helps to find the answer. We 've all experienced that. > Third, the main thrust of your newsgroup argument was that you found that an > issue had already been reported. No no no, you don't get my example related to the Q asked about partially instantiated templates. In this particular case, yes it would have been a duplicate, but it could also be a programming error from mine. This is the whole point of my argumentation. Intead of being a bit humble and to ask yourself if the error could come from you, the first thing you do is to suspect a bug in DMD or Phobos. That's a characterized bias (Congruence bias). > Fourth, I frequently see Andrei and Walter telling people to file bugs for > issues rather than reporting them to the newsgroup. I'm going with their > suggestions rather than yours. I was not suggesting anyone to report bugs in the NG, I was suggesting to ask how to use this or that rather than considering that if you don't manage to do this or that because something it's a bug. But finally the real problem here is that you can't stand my interference, can you ?

"Interference" is the right word. Interference is when an interloper messes about with something in an obstructionist manner. The opposite approach would be ownership, where you actually try to get things done. If you exhibited ownership, you would have edited this bug in place or created a new one and CC'd me on it. That would be the sensible, responsible thing to do for someone who actually cares about problems being fixed.