Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRFC: Selfexhausting iter adapter #2370
Conversation
Emerentius
added some commits
Mar 24, 2018
Centril
added
the
T-libs
label
Mar 24, 2018
Emerentius
added some commits
Mar 24, 2018
scottmcm
reviewed
Mar 26, 2018
| # Implementation | ||
|
|
||
| The `exhausting()` method should take the iterator by value. | ||
| During iteration, `Exhausting` is a trivial wrapper that acts like `&mut Self`, meaning it implements all the Iterator traits that the contained iter implements and will always do external iteration. On drop, it runs `for _ in self {}`. |
This comment has been minimized.
This comment has been minimized.
scottmcm
Mar 26, 2018
Member
Why always external iteration? What would keep it from doing internal iteration with try_fold?
This comment has been minimized.
This comment has been minimized.
Emerentius
Mar 26, 2018
•
Author
You're right. I was confused about internal iteration and the requirement for consumption.
This comment has been minimized.
This comment has been minimized.
main--
commented
Mar 26, 2018
Note that the flag workaround you propose in the drawbacks section is basically a reimplementation of |
Emerentius
referenced this pull request
Jun 12, 2018
Open
Tracking issue for Vec::drain_filter and LinkedList::drain_filter #43244
This comment has been minimized.
This comment has been minimized.
|
Thank you for writing this RFC! The libs team discussed this today, and we felt that this seems too niche of a functionality and that the motivation seemed too weak, especially with the accompanying non-exhausting-drain RFC being postponed for a future unified design that includes other functionality such as filtering-drain. So we’ll likely not add this to the standard library at this time: @rfcbot fcp close Consider experimenting with this API in a crate, possibly in https://crates.io/crates/itertools. |
This comment has been minimized.
This comment has been minimized.
rfcbot
commented
Aug 8, 2018
•
|
Team member @SimonSapin has proposed to close this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
disposition-close
labels
Aug 8, 2018
This comment has been minimized.
This comment has been minimized.
rfcbot
commented
Aug 9, 2018
|
|
rfcbot
added
final-comment-period
and removed
proposed-final-comment-period
labels
Aug 9, 2018
This comment has been minimized.
This comment has been minimized.
|
I had forgotten this was still open. It's a good idea to close it for now. I might bring it up again, if it fits together with an improved generalized drain. |
Emerentius commentedMar 24, 2018
•
edited
Rendered
Add an adapter
.exhausting()toIteratorwhich causes the iterator to be driven to its end on drop. Before dropping it will act exactly like the source iterator.One of two RFCs for splitting the functionality of
draininto two orthogonal APIs.Other RFC: #2369