-
Notifications
You must be signed in to change notification settings - Fork 653
StreamExt::scan
is barely useful due to lifetime issue
#2171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
A-stream
Area: futures::stream
Milestone
Comments
I just ran into this problem and wholeheartedly agree. Something like: fn scan<S, B, Fut, F>(self, initial_state: S, f: F) -> Scan<Self, S, Fut, F>
where
F: FnMut(S, Self::Item) -> Fut,
Fut: Future<Output = Option<(B, S)>>, might perhaps be a better design. |
@ivormetcalf you can use code block quote for better readability. |
Does anyone know of a library that implements @ivormetcalf 's proposed signature? |
michaelbeaumont
added a commit
to michaelbeaumont/futures-rs
that referenced
this issue
Mar 14, 2025
This is the `try_` version of `StreamExt::scan` from master, where the accumulator argument is by value as opposed to by reference, see rust-lang#2171. Additionally, it's placed on `StreamExt` as opposed to `TryStreamExt`, see rust-lang#2342.
michaelbeaumont
added a commit
to michaelbeaumont/futures-rs
that referenced
this issue
Mar 14, 2025
This is the `try_` version of `StreamExt::scan` from master, where the accumulator argument is by value as opposed to by reference, see rust-lang#2171. Additionally, it's placed on `StreamExt` as opposed to `TryStreamExt`, see rust-lang#2342.
michaelbeaumont
added a commit
to michaelbeaumont/futures-rs
that referenced
this issue
Mar 14, 2025
This is the `try_` version of `StreamExt::scan` from master, where the accumulator argument is by value as opposed to by reference, see rust-lang#2171. Additionally, it's placed on `StreamExt` as opposed to `TryStreamExt`, see rust-lang#2342.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Continuing #2046, the lifetime issue is still a headache, that the async block basically cannot access the state when it's executed. Currently, I stick to
futures::stream::unfold
workaround to bind streams with states.. IMO, the future block ofscan
could own the state and returns to stream just like whatunfold
did . Perhaps we can make this change, or are there any other considerations for this design?The text was updated successfully, but these errors were encountered: