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

RFC: Selfexhausting iter adapter #2370

Closed

Conversation

Projects
None yet
6 participants
@Emerentius
Copy link

Emerentius commented Mar 24, 2018

Rendered


Add an adapter .exhausting() to Iterator which 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 drain into two orthogonal APIs.
Other RFC: #2369

# 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.

@scottmcm

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.

@Emerentius

Emerentius Mar 26, 2018

Author

You're right. I was confused about internal iteration and the requirement for consumption.

correct mistake about external iteration
try_fold makes it possible to use internal iteration
@main--

This comment has been minimized.

Copy link

main-- commented Mar 26, 2018

Add exhausting to the FusedIterator trait to side-step the issue of non-fused iterators altogether.

Note that the flag workaround you propose in the drawbacks section is basically a reimplementation of core::iter::Fuse<I>. I think this clearly shows that this API is designed/"wants to" work with fused iterators only, so I'm very much in favor of this alternative.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Aug 8, 2018

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.

@rfcbot

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

rfcbot commented Aug 9, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@Emerentius

This comment has been minimized.

Copy link
Author

Emerentius commented Aug 9, 2018

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.
I'll cut this short and just close it directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.