Skip to content
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

feat: Add sink::from_fn #2254

Closed
wants to merge 4 commits into from
Closed

feat: Add sink::from_fn #2254

wants to merge 4 commits into from

Conversation

Marwes
Copy link
Contributor

@Marwes Marwes commented Nov 4, 2020

Felt the need for this a couple times to mock a sink or inject something
that is sink-like, but doesn't implement sink itself.

Felt the need for this a couple times to mock a sink or inject something
that is sink-like, but doesn't implement sink itself.
@Nemo157
Copy link
Member

Nemo157 commented Nov 4, 2020

See previously #1493, actually capturing state inside the closure is painful.

Comparing the implementations I see two bugs here:

  • poll_ready needs to flush, otherwise it will never return Ready.
  • poll_flush needs to clear the future, otherwise flushing again after it's flushed will panic.

@Marwes
Copy link
Contributor Author

Marwes commented Nov 4, 2020

See previously #1493, actually capturing state inside the closure is painful.

A mutex does the trick when that is necessary 🤷 . There are also cases where there isn't a need to capture state (say pushing to an external database.

@taiki-e
Copy link
Member

taiki-e commented Nov 22, 2020

I have no objection to adding a way to convert impl Fn* -> impl Future to Sink, as sink doesn't currently have an API to do it.

However, I'm not clear if this implementation is preferred. We tried to add something similar to stream (#1609 #1842), but we decided that it would be preferable to provide only unfold due to the limitations of async closure.

So, I'm starting to feel that adding an API like unfold that passes the state separately from the closure is better. @Marwes @Nemo157 Any thoughts?

Marwes pushed a commit to Marwes/futures-rs that referenced this pull request Nov 23, 2020
A more general function than `from_fn` (rust-lang#2254), as suggested in
rust-lang#2254 (comment)
@Marwes Marwes mentioned this pull request Nov 23, 2020
@Marwes
Copy link
Contributor Author

Marwes commented Nov 23, 2020

#2268

@taiki-e
Copy link
Member

taiki-e commented Nov 25, 2020

Closing this in favor of #2268.

@taiki-e taiki-e closed this Nov 25, 2020
taiki-e pushed a commit that referenced this pull request Dec 8, 2020
A more general function than `from_fn` (#2254), as suggested in
#2254 (comment)
zhanghanyun pushed a commit to zhanghanyun/futures-rs that referenced this pull request Dec 8, 2020
A more general function than `from_fn` (rust-lang#2254), as suggested in
rust-lang#2254 (comment)
@taiki-e taiki-e added A-sink Area: futures::sink and removed C-feature-request labels Jan 6, 2021
exrook pushed a commit to exrook/futures-rs that referenced this pull request Apr 5, 2021
A more general function than `from_fn` (rust-lang#2254), as suggested in
rust-lang#2254 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sink Area: futures::sink
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants