1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
use core::iter::FusedIterator;
use core::hash::BuildHasher;
use core::ops::RangeBounds;
use std::collections::BTreeSet;
use std::collections::HashMap;
use std::collections::hash_map::Entry;
pub struct Ranges<'a, T, B> {
map: &'a HashMap<T, BTreeSet<T>, B>,
iter: Option<btree_set::Iter<'a, T>>,
range: Option<(&'a T, &'a T)>,
}
impl<'a, T: Copy + Ord, B: BuildHasher> Ranges<'a, T, B> {
pub fn new(map: &'a HashMap<T, BTreeSet<T>, B>) -> Self {
Ranges {
map,
iter: None,
range: None,
}
}
pub fn range<R>(&mut self, range: R) -> &mut Self
where
R: RangeBounds<T>,
{
self.range = Some((range.start_bound().cloned(), range.end_bound().cloned()));
self
}
}
impl<'a, T: Copy + Ord, B: BuildHasher> Iterator for Ranges<'a, T, B> {
type Item = (&'a T, &'a T);
fn next(&mut self) -> Option<Self::Item> {
// ...existing code...
}
}
// Note: FusedIterator cannot be safely implemented here
// without confirming that once next() returns None,
// subsequent calls will continue to return None.
// This would require analyzing the iterator's internal state management.
// Note: Implementing ExactSizeIterator would require tracking the remaining elements,
// which is complex for Ranges due to its lazy nature and range filtering.
// It's not trivial to implement without significant changes.
// Note: DoubleEndedIterator isn't easily implementable for Ranges because
// it depends on the map keys and nested iteration of BTreeSet entries.
// We would need to significantly restructure how ranges are tracked to support
// efficient bidirectional iteration.