You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Does iter_mut() guarentee stable order if you don't insert/remove elements? #749
An iterator visiting all key-value pairs in arbitrary order, with mutable references to the values. The iterator element type is (&'a K, &'a mut V).
Question on the docs here, if you don't insert/remove elements from the hashmap at all and just do:
hashmap.iter_mut();
hashmap.get_mut() += 1;// updating existing values doesn't mutate the hashmap itself vs insertion/removal
hashmap.iter_mut();//again a few lines down without mutation
Is iteration guaranteed to be stable or can that change one day? I realize I rely on this order being the same. I'm guessing no since there is no test and doc for it so it should not be relied on?
Np, thanks for specifying it in docs. In the event it does happen, can we have a test and changelog in place to warn users? As of now it's stable though, but since it's not a guarantee on all platforms, it really is hard to say 😅
My main thought process is that there may be cases where we might want to enable iterator randomisation somehow, since it's been mentioned a few times before. In those cases, it would likely be enabled via an opt-in feature, and thus you wouldn't be able to reliably ensure it doesn't occur in anything that uses it because of feature unification.
It's a bit of a stretch, but, a potential reason to not explicitly guarantee the order, and to encourage other crates like indexmap in those cases. And, in general, if you want to do a lot of iterating with stable order, indexmap will give you other benefits too, like stable insertion order.
Activity
clarfonthey commentedon Sep 13, 2026
Yes, this is not a guarantee we make and while I also can't imagine it changing, it's probably best to use
indexmapin cases like this.jestarray commentedon Sep 13, 2026
noted, thanks
clarfonthey commentedon Sep 13, 2026
(If you don't mind, going to reopen this to track updating docs.)
jestarray commentedon Sep 13, 2026
Np, thanks for specifying it in docs. In the event it does happen, can we have a test and changelog in place to warn users? As of now it's stable though, but since it's not a guarantee on all platforms, it really is hard to say 😅
clarfonthey commentedon Sep 13, 2026
My main thought process is that there may be cases where we might want to enable iterator randomisation somehow, since it's been mentioned a few times before. In those cases, it would likely be enabled via an opt-in feature, and thus you wouldn't be able to reliably ensure it doesn't occur in anything that uses it because of feature unification.
It's a bit of a stretch, but, a potential reason to not explicitly guarantee the order, and to encourage other crates like
indexmapin those cases. And, in general, if you want to do a lot of iterating with stable order,indexmapwill give you other benefits too, like stable insertion order.