-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Somewhat unhelpful error message "cannot use operator[] with object" #1220
Comments
Sounds like some indication of the argument type should be added to the error message. |
The |
@gregmarr First and foremost, that's just 100% not the issue. Second, the way JavaScript and JSON work is that numeric keys are identical to string keys. So, in practice, In this case, I'm actually making an object where the keys are numbers/numbers converted to strings. It's not an array and there's actually no iteration involved. Also performance is basically irrelevant (the object is like 10 keys big and I wouldn't care if the whole routine took like two seconds (though it currently takes < 20ms because it's just not that hard)). |
That might be how JavaScript works, but it's not how JSON works in other languages. In your case, you can just do the |
@gregmarr All object keys in JSON (the format) must be strings, so it's really just an API/convenience thing, not a language thing. You could argue that anything that is trivially convertible to a string could be a valid argument to the |
Yes, anything that can be trivially converted to a string works. Calling I agreed with you that the error message should say which version of |
I have one question regarding #1221: Do the explanatory strings of exceptions belong to the public API of the library? If so, wouldn't changing be only allowed with a major release? |
@nlohmann I would think the purpose of the error numbers (e.g. 305 in this case) stabilizes this and allows the strings to float. I've thought about this a good amount -- there are very few changes that one could make to a library that don't necessitate a major release if you're being extremely strict. There's almost always a way to detect any changes made in an API (an example might be a check for if a class has a method that results in different behavior), and at a certain point you need to say "If you're relying on this being true, it's your own fault." If the errors didn't have numbers, though, I would agree with you. |
Indexing into an object with a string works fine, as it should. However, indexing into an object with a number does not work, which is acceptable (though perhaps unideal for ergonomics), but the error message is somewhat unhelpful. The error message is:
I think this should note that it is actually possible to use
operator[]
with object, but the argument must be a string.g++ main.cpp --std=c++1z -Wall -o main && ./main
An error message indicating a number cannot be used to index into an object.
An error message indicating one cannot use
operator[]
with an object at all.(remainder of template omitted as I just really think it's noise in this case)
The text was updated successfully, but these errors were encountered: