Skip to content
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

With non-unique keys, later stored entries are not taken into account anymore #963

Closed
jeremysingy opened this issue Feb 7, 2018 · 2 comments
Assignees
Labels
documentation solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@jeremysingy
Copy link

While updating to 3.1.0, I noticed that the behavior of the library is not consistent with the documentation anymore for objects with non-unique names (also discussed in issue #375).

When the names within an object are not unique, later stored name/value pairs overwrite previously stored name/value pairs, leaving the used names unique. For instance, {"key": 1} and {"key": 2, "key": 1} will be treated as equal and both stored as {"key": 1}.

Whereas it will now be treated equally as {"key": 2} instead.

I bissected to the commit 85c7680 replacing operator[] with emplace to insert an object, which will not update an already existing object in the map.

I actually don't need this "feature" anymore, so not sure if it's best to fix the code for consistency or update the corresponding documentation.

@gregmarr
Copy link
Contributor

gregmarr commented Feb 7, 2018

I'm wondering if that behavior should be left unspecified:

When the names within an object are not unique, it is unspecified which one of the values for a given key will be chosen. For instance, {"key": 2, "key": 1} could be equal to either {"key": 1} or {"key": 2}.

@nlohmann
Copy link
Owner

nlohmann commented Feb 9, 2018

I agree - this is more a documentation issue: we over-specified the library's behavior before. I shall change the documentation as @gregmarr proposes.

@nlohmann nlohmann added documentation solution: proposed fix a fix for the issue has been proposed and waits for confirmation and removed confirmed kind: bug labels Feb 9, 2018
@nlohmann nlohmann self-assigned this Feb 9, 2018
@nlohmann nlohmann added this to the Release 3.1.1 milestone Feb 9, 2018
@nlohmann nlohmann closed this as completed Feb 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

No branches or pull requests

3 participants