Add retain_back (aka truncate_front) method to Deque

[nullstalgia]

Howdy again!

I originally intended to do this after championing for the stabilization of alloc's truncate_front method, but it appears someone got to it before me!

Feeling inspired, I jumped right to the heapless implementation like I had done earlier last year for Deque::truncate, using the new name decided for the method in the stabilization PR.

Miri seems happy, and running through the logic on pen and paper it seems sound, but please do let me know if I missed anything or if some more exhaustive tests would be needed!

[zeenix]

Thanks! As usual, I only have nitpicks to offer. :)

[nullstalgia]

@zeenix Since this PR is essentially a continuation of the implementation I did for truncate, am I to apply these same suggested changes to that method as well?

The Safety comments (and overall implementation) I had there and here are essentially copies from the ones from the stdlib's implementation of VecDeque::truncate and truncate_front VecDeque::retain_back. Otherwise there would be unexplained differences in the implementations despite how logically similar they are both between each other here and the stdlib's. Would that fall into the scope of a different PR?

[zeenix]

@zeenix Since this PR is essentially a continuation of the implementation I did for truncate, am I to apply these same suggested changes to that method as well?

Yes please. It's good to be always consistent but please in a separate PR than this.

The Safety comments (and overall implementation) I had there and here are essentially copies from the ones from the stdlib's implementation of VecDeque::truncate and truncate_front VecDeque::retain_back. Otherwise there would be unexplained differences in the implementations despite how logically similar they are both between each other here and the stdlib's.

The important bit is the logic and actual code. As long as they remain as similar as possible, I don't think deviating for improvement, is a problem.

Would that fall into the scope of a different PR?

This would be fixup of this umerged work, so I don't think so.

EDIT: I might have misunderstood you here. I mean, the fixups/changes to the unmerged changes in this PR, should go in this PR. Changes to existing code (already merged) should go into a separate one. I hope it's clear now. :)

[nullstalgia]

Thanks for clarifying, I'll push the requested changes + submit an accompanying PR soon.

[zeenix]

lgtm otherwise.

[zeenix]

ok, time for merge then but before that, please rebase on master/main (instead of merging that) to keep the history easier to follow (and avoiding unrelated commits in the PR).

[nullstalgia]

Alrighty, should be good to go! Thanks for helping see this PR through, hopefully they (t-libs) don't change the method name on us again! ;P