A version of `fold` that works with mutable modifications of the accumulator, instead of returning a new one

[TomFryersMidsummer]

Call it, say, fold_mut. Essentially, fold_mut is to FnMut(&mut B, T) as fold is to FnMut(B, T) -> B. This solves the annoying case of having to write code like the fast_union function below.

Here's an implementation and example use case:

trait Itertools_: Iterator {
    fn fold_mut<B>(self, init: B, mut f: impl FnMut(&mut B, Self::Item)) -> B
    where
        Self: Sized,
    {
        self.fold(init, |mut b, x| {
            f(&mut b, x);
            b
        })
    }
}

impl<T, I: Iterator<Item = T>> Itertools_ for I {}

type Set = std::collections::HashSet<u32>;

fn clean_union(sets: impl Iterator<Item = Set>) -> Set {
    sets.fold(Set::new(), |a, b| &a | &b)
}

fn fast_union(sets: impl Iterator<Item = Set>) -> Set {
    sets.fold(Set::new(), |mut a, b| {
        a.extend(b);
        a
    })
}

fn both_union(sets: impl Iterator<Item = Set>) -> Set {
    sets.fold_mut(Set::new(), Extend::extend)
}

This isn't tremendously simpler than the code it replaces; it's more of an Itertools::sorted than an Itertools::tuple_combinations.

[phimuemue]

Hi there. I know the problem, but it is not iterator- and particulary not fold-specific and can be solved by lifting the function from Fn(&mut A, B) to Fn(A, B)->A:

#![feature(option_zip)]

macro_rules! mutate_return {
    ($f: expr) => {
        |t, a0| t.mutate_return($f, a0)
    };
}

pub trait TMutateReturnSelf: Sized {
    fn mutate_return<A0, F: FnMut(&mut Self, A0)>(mut self, mut f: F, a0: A0) -> Self {
        f(&mut self, a0);
        self
    }
}
impl<T: Sized> TMutateReturnSelf for T {}

fn main() {
    dbg!(vec![1,2,3].into_iter().fold(Vec::new(), mutate_return!(Vec::push)));
    
    dbg!(vec![vec![1], vec![2], vec![3]].into_iter().reduce(mutate_return!(Vec::extend)));
    
    dbg!(Some(vec![]).zip_with(Some(1), mutate_return!(Vec::push)));
}

Moreover, fold_mut is possibly close enough to for_each.

Thus, closing this.

[scottmcm]

Moreover, fold_mut is possibly close enough to for_each.

Yes, this. for_each takes FnMut, so if you need to mutate something go for it; there's no need to thread that through the arguments of the lambda every time. See rust-lang/rust-clippy#6053 suggesting that clippy should tell you this if you don't need move access to the accumulator.

(See also #481 from last time fold_mut came up in itertools after it was rejected from core.)

[TomFryersMidsummer]

Ah, I see:

fn both_union_but_without_adding_extra_features(sets: impl Iterator<Item = Set>) -> Set {
    let mut result = Set::new();
    for s in sets {
        result.extend(s);
    }
    result
}

It's a bit more verbose, but extremely clear, and the loss of terseness is smaller when, as is pretty likely in real cases, you only have a type implementing IntoIterator.

I only searched issues, so missed that previous PR – sorry.

[scottmcm]

Yup! Or, to look more like fast_union (but one line shorter),

pub fn both_union(sets: impl Iterator<Item = Set>) -> Set {
    let mut a = Set::new();
    sets.for_each(|b| a.extend(b));
    a
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=0756456520cecf9f40eca7d682bf808f