-
Notifications
You must be signed in to change notification settings - Fork 21
Inconsistent hashCode with mapValues #10863
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
Comments
(@Robert-Morewood I think you need a line break before |
For some reason, the lambda in the map seems to be generated anew each time you do something with the map |
This is probably another consequence of |
@NthPortal Thanks for the syntax correction! I had a semi-colon in my test code... @hrhino I suspect that mapValues is misreprented. That lazy evaluation effectively makes it a View rather than a Map, but hashCode is treating it as the Map it claims to be. If we instead do: |
That's an interesting spin on an old chestnut. The canonical issue is #4776. There was just #10663 about hashCode when converting. I was a little surprised that converting doesn't force; in the sense that nothing surprises me.
|
already fixed in the new collections, which are coming in 2.13.0-M4. closing because I doubt this can be fixed in the 2.12.x series without breaking compatibility (although if someone has an idea of how to do that we could reopen, I haven't thought deeply about it) in the new collections, |
A cheap fix/mitigation would be to tweak the Edit: I'm not sure why I thought this would help with |
@NthPortal I updated the title to help us recall what we were talking about, in case it comes up later. |
Uh oh!
There was an error while loading. Please reload this page.
The following mapValues snippet might be expected to return true:
val aMap = Map(0->0).mapValues(y => ((x: Int) => x + y)); aMap.hashCode == aMap.hashCode
However it returns false where I have tested it:
(A trivialized example of a problem that did affect our production code.)
The above behaviour violates the Java documentation on hashCode : https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode--
For anyone else bothered by this behaviour, applying .view.force to the mapValues result produces a real map with a consistent hashCode, at the cost of evaluating and storing the mapValues expression for every value in the original map.
The text was updated successfully, but these errors were encountered: