Add itertools::generate

[matklad]

closes #298

No tests yet, will add them if we indeed want this in itertools :-)

[matklad]

Here's another example where generate simplifies stuff: rust-lang/rust-analyzer@a7d31b5?diff=split#diff-32acdb3e3f79ef45c2a6a0569d3812ddL16

I think I could've coded the original version better, by using Option<CurrentState>.take() pattern instead of that awkward bool, but it is hard to invent when you try to actually traverse that tree with parent pointers in O(1) stack space :)

[bluss]

thanks this looks very nice. The difference vs unfold makes sense. Maybe we can call out the difference more explicitly, or that the seed value is produced as the first value at least?

Why the choice to make the seed input parameter an Option? That seems to be the awkward concession with this API. I wonder if we can make it a plain value, and then the resulting iterator is always at least a sequence of one element.

[matklad]

seed being optional feels canonical: it allows for empty sequences and exactly matches the repr of the oterator. In practice, it is indeed the case that non-empty case is more common, but empty one is occasionally useful as well. Kotlin handles this gracefully because ? turns out to be more ergonomic than option in this case.

I think a way forward is to remove option here, and than maybe make the Generate::new public factory function which accepts an Option?

[matklad]

Pushed up update & some test :-)

[matklad]

Here's a real-world example where I need Option for a seed:

https://github.com/matklad/libsyntax2/blob/8b0298ce095b6dd635f7ed35dc97f1874157040b/crates/libeditor/src/completion.rs#L114-L121

[Emerentius]

I've defined a similar function for myself a couple of times like this:

fn generator<T>(mut advance: impl FnMut() -> Option<T>) -> impl Iterator<Item = T> {
    std::iter::repeat(()).scan((), move |(), ()| advance())
}

Which relies completely on closure captures. I think you don't really need a seed for generality. It may simplify the closure, but it forces a check that may be impossible to fail (infinite iterator) .

[matklad]

friendly ping @bluss :) Saw you on both internals and GitHub today ;)

[matklad]

CI is failing due to #302 , IIRC

[matklad]

std now has unstable successors function, so this can be closed now!