Add an Iterate iterator

[ghost]

The new iterator takes a function and produces an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.

[ghost]

Needless to say, I'm not too happy about the name.

[alexcrichton]

This may not be failure-safe because any failure will attempt to drop the zeroed next_arg field. Why not store Option<A>?

[ghost]

Right! I changed it to use Option (and noticed I couldn't use Option::mutate as it takes a bare function, which maybe it shouldn't?).

[huonw]

and noticed I couldn't use Option::mutate as it takes a bare function, which maybe it shouldn't

It takes a closure AFAICT: Option.mutate?

[ghost]

@huonw Oh dear, yes. I got really confused by the error message. Learning Rust every day!

[bluss]

It is similar but less general than the already present std::iter::Unfold. Less general means that it's easier to use, of course.

// Doubling sequence: 1, 2, 4, 8, ..
std::iter::Unfold::new(1i, |st| {let elt = *st; *st *= 2; Some(elt) });

[lilyball]

This is nearly identical to Unfold except that

1. The closure returns T instead of Option<T>, which means it's strictly less powerful
2. The initial seed is returned from the first call to .next(), whereas Unfold runs the closure first.

Also, bizarrely, it runs the closure on next() but doesn't return the value from that call until the next next(). This means that any side effects that the closure may have will occur at a rather unexpected time.

Overall, I don't see the point in having a near-duplicate of Unfold.

[huonw]

Also, bizarrely, it runs the closure on next() but doesn't return the value from that call until the next next(). This means that any side effects that the closure may have will occur at a rather unexpected time.

This isn't that bizarre: it makes std::iter::Iterate::new(1, |x| x * 2) give 1, 2, 4, 8, ..., while not returning the old value makes giving such a sequence harder. It also matches Haskell's iterate.

[lilyball]

@huonw That's an artifact of returning the seed, not an artifact of running the closure early. Note that Haskell's iterate does not evaluate the thunk for the next value before you actually need that value (which isn't something special about iterate of course).

The reason that Iterate runs the closure early, of course, is because of how it's implemented internally, because of its need to return the seed. This could be fixed by using a two-state enum.

[lilyball]

If this behavior is useful, perhaps we should just have a free function fn std::iter::iterate<'a, T>(f: |T|: 'a -> T, seed: T) -> Unfold<'a, T>. This could be done by adding the necessary state to Unfold, or it could even by done purely as a wrapper that puts the necessary state into the state value.

This could also be done as a static method on Unfold if using a free function is considered odd.

[lilyball]

use std::iter::Unfold;

// FWIW this is a great example of where an `exists` existential type operator
// would be nice, so we could avoid defining the St parameter to Unfold.
// Instead I'm just going to use a non-public type.
type IterateSt<'a,T> = (|T|: 'a -> T, Option<T>, bool);

#[allow(visible_private_types)]
pub fn iterate<'a, T: Clone>(f: |T|: 'a -> T, seed: T) -> Unfold<'a, T, IterateSt<'a, T>> {
    Unfold::new((f, Some(seed), true), |st| {
        let &(ref mut f, ref mut val, ref mut first) = st;
        if *first {
            *first = false;
        } else {
            val.mutate(|x| (*f)(x));
        }
        val.clone()
    })
}

[ghost]

@kballard Agreed the previous implementation had bizarre characteristics around when the next value is computed.

I took the liberty of using your last implementation, thank you very much. I think a free-standing function is a better fit for this. Arguably, all iterators are just specializations of Unfold. This one's really close but I think the readability win is significant that it still warrants being included in core.

[lilyball]

👍 r=me unless @huonw, @alexcrichton, or @blake2-ppc disagree.

[bluss]

If you ask me iterate should have its own either struct or type if it is part of std::iter -- it's a module for conveniently reusable items, so the type returned by iterate() needs to be easy ("easy") to use in user's iterator compositions.

[lilyball]

Good point. A pub type I think is sufficient. No need to make a custom struct.

[alexcrichton]

Looks good to me with pub type.

[ghost]

@blake2-ppc @kballard @alexcrichton Done.