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: Non-selfexhausting Drain #2369

Closed

Conversation

Projects
None yet
5 participants
@Emerentius
Copy link

Emerentius commented Mar 24, 2018

Rendered


Add *_nonexhausting() variants for every drain() that do not eagerly consume residual items on drop of the DrainNonexhausting struct.


One of two RFCs for splitting the functionality of drain into two orthogonal APIs.
Other RFC: #2370

@scottmcm

This comment has been minimized.

Copy link
Member

scottmcm commented Mar 26, 2018

Another possible alternative: a method on the Drain type like fn keep_remaining(self) that consumes it without removing the as-yet-uniterated elements. (Sample implementation for Vec in https://internals.rust-lang.org/t/pre-rfc-lazy-drain-and-self-exhausting-iterators/7037/8?u=scottmcm)

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Mar 28, 2018

This RFC came up when the libs team discussed the unstable drain_filter method rust-lang/rust#43244 and the consensus was to not stabilize more drain-like methods at the moment.

We’d like to see experimentation to attempt to generalize into a smaller API surface various combinations of draining:

  • A sub-range (through RangeArgument a.k.a. RangeBounds) v.s. the entire collection (though the latter could be achieved by passing .., a value of type RangeFull).
  • Draining everything (possibly within that range) v.s. only elements that match a boolean predicate
  • Self-exhausting on drop v.s. not (leaving the rest of the elements in the collection).

Possibilities might include "overloading" a method by making it generic, or a builder pattern.

(One constraint is that the drain method is stable. It can possibly be generalized, but only in backward-compatible ways.)

This would likely be in a new RFC rather than taking this one as-is:

@rfcbot fcp postpone

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Mar 28, 2018

Team member @SimonSapin has proposed to postpone 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 Mar 29, 2018

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

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Apr 8, 2018

The final comment period is now complete.

@Centril Centril added the postponed label Apr 9, 2018

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Apr 9, 2018

This RFC is now postponed per the review above.

Thanks to @Emerentius!

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.