4 ms·
I never said once that the implementation is incorrect, just that it is weird and uncommon.
by kokada 2y ago
I never said once that the implementation is incorrect, just that it is weird and uncommon.
- coldtea 2y agoYes, but the expectation for non-weirdness is not based on the actual specs a hashmap must have, just on contingencies ("but no other language I know does it like this") that apply to quite narrow criteria (iterating over statically added hashmap entries, if you added entries from a dynamic source, or added them in parallel, etc, they could very well change for every run without the language randomizing anything explicitly).
- kokada 2y agoThat is still a valid expectation, just look at other commenters on the thread that they also find the behavior surprising.
- pests 2y agoI agree with you but I do see his perspective. "Hashmaps make no guarantee about iteration order" does not imply the implementation is going to do _EXTRA WORK_ to make that true. It being ordered, or providing a guarantee of some order, is still within spec of the hashmap concept. To expend extra cycles to force no order, when any order is fine (esp if it falls out of the data structure), is extra work. Its an extra constraint, one a hashmap does not require. I wonder how much energy we have collectively spent sorting lists for no reason.