`unfold` API seems less than ideal

[matklad]

Hi! recently, I've been using unfold a couple of times, and looks like it's rather tricky, at least in comparison with Kotlin's generateSequece.

I see two problems with current unfold API:

• There's two ways to maintain state: you can use the initial_state, or you can just close over some env (I think these are equivalent in power).

• There'a common case when the state and the Item of the iterator are the same. In this situation, you need to be careful to update the state, but return a previous value.

It seems to me that, instead of unfold, ideally there should be a couple of function:

• repeat_call, for explicitly closing over some state and handling updates.

• generate<T>(first: Option<T>, step: impl FnMut(&T) -> Option<T>) -> impl Iterator<Item=T> for the common case.

Here's an example usage, which compares unfold and generate:

https://github.com/matklad/libsyntax2/blob/557feed21ab4f1a6473b5f79e6ef250cf1219857/crates/libeditor/src/code_actions.rs#L42-L53

The second one looks much clearer to me :)

Or am missing some property of generate, which makes it more powerful than repeat_call or easier to use than generate?

[matklad]

Send a PR with generate implementation. I've also noticed that the state field of Unfold is public, which indeed makes it a more general API. Perhas unfold's example should be changed to something which makes use of this feature?

[bluss]

You are right the current unfold example is just a fun switcheroo I did (at some point in the commit history), from explicit state to closure captures, but we can switch that right back. It's redundant to have both available, in a way.

[bluss]

This seems to be handled by std now. I'll add unfold to the potentially-to-remove list in itertools: #223