Add iter ops

[saik0]

Closes #58
Closes #109
Fixes #57

Adds operators to iterators of bitmaps

TODO

• Treemap ops
• Tests
• Examples in docs

[Kerollmops]

I am not sure why you want to restrict this trait to our library types? What's dangerous in implementing that on, for example, a wrapper of RoaringBitmap/Treemap?

[saik0]

Adding new non-defaulted methods would be a breaking change downstream. I was thinking this was for public API compatibility.

[Kerollmops]

I would say that it would be a "soft" breaking if we add new methods to a trait. I would prefer that we make it free for users to implement, at least for a first release.

[Kerollmops]

Maybe we could find a better name for this trait, as it is a trait that provides set operations on multiple sets at the same time, maybe MultiOps, RoaringExt or something like that? What do you think?

[saik0]

Sure. We could also create a Roaring prelude that includes iter extensions, RoaringBitmap, RoaringTreemap

[Kerollmops]

Hum... not sure we have enough types and traits for now for that to be interesting, but maybe later with more types.

[saik0]

I see value in exposing an API for lazy ops regardless of whether or not we expose the iterator extensions that use them internally. To generalize to any kind of aggregation the user might need to do. The intuition is to have an API that allows users to do lazy operations with a newtype, that gets "repaired" (to use the same term as other lang impls) when it's unwrapped.

Thinking out loud in pseudo-rust about the shape of the API, not the names.

struct Lazy {
  bitmap: RoaringBitmap
}

impl BitOrAssign<&Lazy> for Lazy {
 // .. do a lazy or
}

impl BitXorAssign<&Lazy> for Lazy {
 // .. do a lazy xor
}

impl RoaringBitmap {
  fn into_lazy(self) -> Lazy
}

impl Lazy {
  /// ensure all the stores are the correct type before unwrapping (repairAfterLazy in other langs)
  fn into_bitmap(self) -> RoaringBitmap
}

fn main() -> {
  // Roughly equivalent to current IterExt (this does not use Cow)
  let bitmaps: Vec<RoaringBitmap> = todo!();
  bitmaps.into_iter().map(RoaringBitmap::into_lazy).reduce(|acc, other| { acc |= other; acc }).into_bitmap();

  // Now do it in parallel!
  use rayon::prelude::*;
  let more_bitmaps: Vec<RoaringBitmap> = todo!();
  bitmaps.into_par_iter().map(RoaringBitmap::into_lazy).reduce(|acc, other| { acc |= other; acc }).into_bitmap();
}

I'd need to think more about what it might look like for borrowed bitmaps. 🤔

[Kerollmops]

To generalize to any kind of aggregation the user might need to do. The intuition is to have an API that allows users to do lazy operations with a newtype, that gets "repaired" (to use the same term as other lang impls) when it's unwrapped.

I like the idea, but we must absolutely make sure to document it enough. That's not clear what a Lazy type does. I like the idea of wrapping the bitmaps instead of methods to do lazy operations on them. I like the Lazy wrapping type as it look a lot like the Wrapping struct of the std.