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 custom nth_back to Skip #60454

Merged
merged 1 commit into from
Jun 20, 2019
Merged

Add custom nth_back to Skip #60454

merged 1 commit into from
Jun 20, 2019

Conversation

acrrd
Copy link
Contributor

@acrrd acrrd commented May 1, 2019

Implementation of nth_back for Skip.
Part of #54054

@rust-highfive
Copy link
Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 1, 2019
@cramertj
Copy link
Member

cramertj commented May 1, 2019

r? @scottmcm

@rust-highfive rust-highfive assigned scottmcm and unassigned cramertj May 1, 2019
@timvermeulen
Copy link
Contributor

Looks correct to me, though I don't think we want nth_back to skip any of the elements at the front, similar to how next_back doesn't skip any. I think we can call self.iter.nth_back(n) as long as n < self.len(), without having to involve self.n.

@acrrd
Copy link
Contributor Author

acrrd commented May 2, 2019

Didn't notice that, I changed it

@scottmcm
Copy link
Member

scottmcm commented May 9, 2019

Look good, thanks!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 9, 2019

📌 Commit 1edecacf2021a3381f447c949e6dc3018f4b0be4 has been approved by scottmcm

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 9, 2019
@bors
Copy link
Contributor

bors commented May 9, 2019

⌛ Testing commit 1edecacf2021a3381f447c949e6dc3018f4b0be4 with merge 8e9bb42c1edf098a01f7a18737f23ad257978854...

if n < self.len() {
self.iter.nth_back(n)
} else {
None

This comment was marked as resolved.

@scottmcm
Copy link
Member

scottmcm commented May 9, 2019

@bors r-

Good point, @sinkuu; Thanks!

@acrrd Can you add some more tests for bigger n, and maybe some with by_ref to ensure behavior doesn't change here?

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 9, 2019
@kennytm
Copy link
Member

kennytm commented May 9, 2019

@bors r- retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 9, 2019
@acrrd
Copy link
Contributor Author

acrrd commented May 9, 2019

@sinkuu thanks!

@scottmcm I added the test for a bigger n and another test that check that nth_back behave as a non skipped iterator. It's not clear to me how to do the tests you meant using by_ref

@timvermeulen
Copy link
Contributor

I don't think we want nth_back to skip any of the elements at the front, similar to how next_back doesn't skip any

Isn't this still a concern with the current implementation?

@acrrd acrrd force-pushed the issues/54054_skip branch 2 times, most recently from b7fe202 to edd4879 Compare May 27, 2019 20:22
@acrrd
Copy link
Contributor Author

acrrd commented May 27, 2019

@timvermeulen thanks :)

fn nth_back(&mut self, n: usize) -> Option<I::Item> {
if n < self.len() {
self.iter.nth_back(n)
} else {
Copy link
Contributor

@sinkuu sinkuu May 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case n >= self.len() && self.len() != 0, additionally you need to do self.iter.nth_back(self.len() - 1); (or whatever that takes self.len()-items from the back) since the underlying iterator could have side effects.

let mut v = vec![];
let mut it = [1, 2, 3, 4, 5]
    .iter()
    .cloned()
    .inspect(|x| v.push(*x))
    .skip(1);
assert_eq!(it.len(), 4);
assert_eq!(it.nth_back(4), None);
assert_eq!(v, vec![5, 4, 3, 2]);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why let _ = and not just the call to nth_back?

Copy link
Contributor

@sinkuu sinkuu May 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was just for expressing intent to throw away the return value of nth_back, and I don't meant it is actually needed.

@@ -2280,6 +2280,32 @@ fn test_skip_try_folds() {
assert_eq!(iter.next_back(), Some(24));
}

#[test]
fn test_skip_nth_back() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the comment above was addressed; if disagree please add a test that demonstrates that the underlying iterator is still advanced.

(You could do that with inspect, or something like let mut it = ...; it.by_ref().skip(10).nth_back(100); assert_eq!(it.next_back(), ...);)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I didn't understand you meant that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're now calling self.len() three times, maybe it's better to store it in a variable first.

@acrrd acrrd force-pushed the issues/54054_skip branch 2 times, most recently from 8e83410 to 2966f58 Compare May 29, 2019 20:13
@jonas-schievink
Copy link
Contributor

Ping from triage, @acrrd what's the status of this? Are there still open review comments to be addressed, or is this waiting on someone to approve?

@acrrd
Copy link
Contributor Author

acrrd commented Jun 19, 2019

@jonas-schievink I think all comments are addressed, waiting for approval.

@jonas-schievink jonas-schievink added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 19, 2019
@scottmcm
Copy link
Member

Sorry for the delay re-reviewing, this looks great now!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 20, 2019

📌 Commit e80a375 has been approved by scottmcm

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 20, 2019
Centril added a commit to Centril/rust that referenced this pull request Jun 20, 2019
Add custom nth_back to Skip

Implementation of nth_back for Skip.
Part of rust-lang#54054
bors added a commit that referenced this pull request Jun 20, 2019
Rollup of 4 pull requests

Successful merges:

 - #60454 (Add custom nth_back to Skip)
 - #60772 (Implement nth_back for slice::{Iter, IterMut})
 - #61782 (suggest tuple struct syntax)
 - #61968 (rustc: disallow cloning HIR nodes.)

Failed merges:

r? @ghost
@bors bors merged commit e80a375 into rust-lang:master Jun 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants