New Itertools::tail

[Philippe-Cholet]

Hi, after 80 merged PRs fixing, modifying, testing, benchmarking, specializing or whatever really... I just checked this is my first PR where I actually add a "brand new" feature myself. 🤣

PS from the future: The discussion also lead me to contribute a small optimization inside VecDeque::pop_{back,front} that will be released in rust 1.79.0. 😎

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.50%. Comparing base (6814180) to head (b51f26a).
Report is 36 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #899      +/-   ##
==========================================
+ Coverage   94.38%   94.50%   +0.11%     
==========================================
  Files          48       48              
  Lines        6665     6807     +142     
==========================================
+ Hits         6291     6433     +142     
  Misses        374      374              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Philippe-Cholet]

I wonder if libcore would want a Iterator::tail<const N: usize> (not as straightforward as this implementation in case the iterator generate less than N items but it's possible) in which case name my method Itertools::tail(n: usize) would clash.

But we could then wonder about k_smallest and its variants where [_; N] is enough storage.

[Philippe-Cholet]

I fused the iterator instead of checking data.len() == n (same as recent fix #900).

[scottmcm]

Pondering naming: would it be worth a name that more directly emphasizes the allocating or the approach? Like a too-long name might be collect_last_n. I wonder how best to make it clear that this isn't lazy like take.

Relatedly, I'm curious how people would expect this to behave and what trait bounds they'd expect. I often expect things looking at the end of an iterator to want DoubleEndedIterator, but this is very much a "look, I need to look at the end but I don't have a double-ended iterator" kind of thing.

So I wonder if tail would make more sense for something using the *_back methods, and this version should have a longer name of some sort.

[Philippe-Cholet]

We are not doing const-generics yet but I'm sometimes thinking about it.

match iter.next_chunk() { // I want this stabilized BTW.
    Ok(arr) => {
        /*update; rotate;*/
        arr.into_iter()
    }
    Err(arr_iter) => arr_iter,
}

All that to say it would return core::array::IntoIter and that VecIntoIter seems the right type and I would expect a simple Vec from collect_....

I'm also wondering if tail is the best name but I did not find a better one.

[phimuemue]

Hi @Philippe-Cholet, looks reasonable.

I approve this so that you can merge, but I'd appreciate a second pair of eyes, maybe @scottmcm?

[scottmcm]

"Product" code looks good, though you probably want some test+doc updates before merging.

[Philippe-Cholet]

I polished the commits and added @scottmcm as co-author.
I particularly like his idea of skipping the starting part of the iterator.

Is there a better name than tail? (see this)
If not then I think this can be merged.

Note for myself: File a rust issue for a possible method more optimized than .pop_front()+.push_back(_), compared to my vector implementation (see this).

EDIT: Discussion there.