into_iter(_all) would to avoid clone

[schrieveslaach]

It would be vary handy if MultiMap would provide following methods to avoid potential calls of clone when massaging data:

pub fn into_iter(self) -> Iter<K, V> {
        // …
}

pub fn into_iter_all(self) -> IterAll<K, Vec<V>> {
        // …
}

[havarnov]

Sounds good. PR is welcome 👍

[schrieveslaach]

I watched Crust of Rust: Iterators and now I think that impl<K, V, S> IntoIterator for MultiMap<K, V, S> should return a custom iterator that also implements Flatten. That would make following possible in idiomatic Rust:

let all_values = map.into_iter()
  .flatten()
  .map(|(_k, v)| v)
  .collect::<Vec<_>>();

What do you think? I'm happy to provide a PR.

[havarnov]

Maybe it should've, but that would be a breaking change for a rather minor feature. Or what do you think?

For the flatten() suggestion, I think you can do the following.

let all_values = map
            .into_iter()
            .map(|(_, v)| v)
            .flatten()
            .collect::<Vec<_>>();

or

let all_key_value_pairs = map
            .into_iter()
            .map(|(k, v)|
                v.into_iter().map(move |i| (k, i)))
            .flatten()
            .collect::<Vec<_>>();

[schrieveslaach]

To the best of my knowledge that shouldn't be a breaking change because a consumer shouldn't rely on the specific type of iterator that is returned by into_iter(), which isn't idiomatic. As long as the return type implements std::iter::Iterator the consumer is fine. Only following would be a breaking change:

// not idiomatic
let iter : std::collections::hash_map::Iter<'_, K, V> = map.into_iter();

[havarnov]

@schrieveslaach I have to disagree on that not being a breaking change. Anyways, I'll add this to the 1.0.0 milestone.