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

Add Iterator::at_least() and Iterator::at_most() API #80835

Closed
wants to merge 9 commits into from

Conversation

Folyd
Copy link
Contributor

@Folyd Folyd commented Jan 9, 2021

at_least() and at_most() are similar to any() and all(), these two methods test if at least/most n elements of the iterator matches a predicate.

Although, we can simply use iter.filter().count() > n , at_least() and at_most() are short-circuiting, so it's more effecency than the simple filter in most cases.

I have created a benchmark project to demonstrate three versions of at_least, here is the repository link.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 9, 2021
@rust-log-analyzer

This comment has been minimized.

@the8472
Copy link
Member

the8472 commented Jan 9, 2021

Although, we can simply use iter.filter().count() > n , at_least() and at_most() are short-circuiting, so it's more effecency than the simple filter in most cases.

Well, that effect could also be achieved by adding a take(n) before the count().

@rust-log-analyzer

This comment has been minimized.

@kennytm kennytm added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 10, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jan 16, 2021

☔ The latest upstream changes (presumably #81089) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

@Folyd
Copy link
Contributor Author

Folyd commented Feb 1, 2021

@the8472 TIL. Good point. Thanks. 😄

So I'm wondering why the implementation of Iterator::any() is based on ControlFlow ranther than something like filter(|f| f()).take(1).count() > 0?

@JohnCSimon JohnCSimon added S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. labels Feb 23, 2021
@bors
Copy link
Contributor

bors commented Mar 10, 2021

☔ The latest upstream changes (presumably #82953) made this pull request unmergeable. Please resolve the merge conflicts.

@crlf0710
Copy link
Member

r? @m-ou-se

@crlf0710
Copy link
Member

Triage: There's merge conflicts now. @Folyd

@m-ou-se
Copy link
Member

m-ou-se commented Mar 27, 2021

@Folyd Thanks for your PR!

Do you have some motivating examples? While .any() and .all() seem like very common operations to me, I can't think of many common situations where .at_least() and .at_most() would be used. Considering the very large amount of methods we already have on Iterator and that .filter().take() already suffices in most (all?) of those situations, I'm hesitant to merge this.

@m-ou-se m-ou-se added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 27, 2021
@Folyd
Copy link
Contributor Author

Folyd commented Apr 1, 2021

@Folyd Thanks for your PR!

Do you have some motivating examples? While .any() and .all() seem like very common operations to me, I can't think of many common situations where .at_least() and .at_most() would be used. Considering the very large amount of methods we already have on Iterator and that .filter().take() already suffices in most (all?) of those situations, I'm hesitant to merge this.

Thanks, @m-ou-se. I agree with you. Let's close this. 👌

@Folyd Folyd closed this Apr 1, 2021
@Folyd Folyd deleted the iter-atleast-atmost branch January 4, 2023 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants