Fix PadUsing::next_back#1082
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1082 +/- ##
==========================================
- Coverage 94.38% 93.68% -0.70%
==========================================
Files 48 50 +2
Lines 6665 6322 -343
==========================================
- Hits 6291 5923 -368
- Misses 374 399 +25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi @jswrenn, gentle nudge about this. If it helps, you can consider this reviewed. I did not/do not know how I could take @Takashiidobe's original PR and rebase it to this one. And afaik I cannot just push to this repo. |
jswrenn
left a comment
There was a problem hiding this comment.
Thanks for the nudge, and sorry for the absence; I've been ramping up in a new day job. This looks fantastic! Can you just add Fixes: #1065 to the commit message?
…ements_from_next_back Remove fold/rfold: Correctness is more important than performance. Maybe we can come back and re-implement them later. Fixes: rust-itertools#1065
Nevermind. Congrats on the new job.
Done. Sidenote: Should we publish a new version soon? Would simplify CI (currently always complains about |
6c2e8f6
This is a consolidated version of @Takashiidobe's #1079. Thanks, @Takashiidobe, for your effort.
Test
next,next_backexplicitly: Simulatepad_usings result with aVecandassertthat they behave the same wrtnext/next_back.Fix: Store
elements_from_nextandelements_from_next_back.The story is:
total_consumed = elements_from_next + elements_from_next_back. Iftotal_consumed >= elements_required, we can be sure that we only need to touchiter(and notfiller). See Fixpad_usingbug producing items when it shouldn't #1079 for more discussion.For simplicity, only implement
next,next_backandsize_hintfor now.