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

Emerentius
Copy link

@Emerentius 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

@Centril Centril added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Mar 24, 2018
@scottmcm
Copy link
Member

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
Copy link
Contributor

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
Copy link
Collaborator

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 rfcbot added the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Mar 28, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 29, 2018

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

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Mar 29, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Apr 8, 2018

The final comment period is now complete.

@Centril Centril added the postponed RFCs that have been postponed and may be revisited at a later time. label Apr 9, 2018
@Centril
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
Labels
final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. postponed RFCs that have been postponed and may be revisited at a later time. T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants