search

Ralith / sieve-tree

6 stars 1 forks source link

Some kind of optional removal during intersection testing could be helpful #4

Closed grovesNL closed 5 days ago

grovesNL commented 6 days ago

With BTreeMap's range iterators it's possible to remove keys while you're iterating through a matching range. This is convenient for some use cases where you're looking for intersections to merge together, because you can avoid having a queue of elements to update/remove after the intersection test.

It would probably be non-trivial to support this based on how the intersection iterator needs to work, but I thought I'd mention it here in case there's a way we could make this work. Maybe it could be something like a draining iterator that can be cancelled per element that performs the removals in bulk at the end.

Ralith commented 5 days ago

With BTreeMap's range iterators it's possible to remove keys while you're iterating through a matching range

Can you link the API? I don't see it.

grovesNL commented 5 days ago

Actually it looks like that's my mistake, I misremembered this somehow. I might have been thinking of the proposed BTreeMap cursor API that should allow for something similar to this.

This could also be possible for some special kind of iterator that just tracked how far you've advanced through the queried range (if you avoid holding references to the map and instead pass it down), but you could wrap sieve-tree to do that on your own anyway.