Repository navigation
Can iterators of SlotMap and SecondaryMap safely be joined? #121
Description
Iterators very explicitly say, that the visit key-value pairs "in arbitrary order".
Is this "arbitrary order" consistent between a SlotMap and its dependent SecondaryMaps, so they can be joined (assuming they contain exactly the same keys in the same version)?
Is the following guaranteed to work, or is it working just an accident?
let mut a = SlotMap::new();
let mut b = SecondaryMap::new();
let mut c = SecondaryMap::new();
let idx0 = a.insert(0);
let idx1 = a.insert(1);
let idx2 = a.insert(2);
b.insert(idx0, 0);
b.insert(idx1, 1);
b.insert(idx2, 2);
c.insert(idx0, 0);
c.insert(idx1, 1);
c.insert(idx2, 2);
c.remove(idx1);
b.remove(idx1);
a.remove(idx1);
for (((a_key, a_val), (b_key, b_val)), (c_key, c_val)) in a.iter().zip(b.iter_mut()).zip(c.iter()) {
assert_eq!(a_key, b_key);
assert_eq!(a_key, c_key);
assert_eq!(a_val, b_val);
assert_eq!(a_val, c_val);
}
Activity
orlp commentedon Jul 16, 2024
At the moment this is not guaranteed but should work. For a
DenseSlotMapit won't work. I'd like to guarantee this actually works inslotmap2.0.NeverGivinUp commentedon Jul 16, 2024
That's great. Indexing in a FxHashMap with slot-map keys is about the same speed as indexing in a SecondaryMap. But iterating a SecondaryMap is so much faster than iterating a FxHashMap. Since performance is the only reason I use slot-maps not having to index into a secondary map while iterating is very important for me. Looking forward to slotmap 2.0, then. Do you already have any estimates wtr. publication date and the amount of API changes?