Fix IteratorRandom::sample and sample_fill consuming the iterator when amount == 0

[teddytennant]

• Added a CHANGELOG.md entry

Summary

Make IteratorRandom::sample and sample_fill return early when amount == 0 instead of consuming the iterator and advancing the RNG.

Motivation

With amount == 0, sample_fill skips the initial fill loop (len < amount is immediately false) and sample's take(0) reservoir is empty, so both fall through to the reservoir-sampling loop. That loop walks the entire remaining iterator and draws one random index per element, even though nothing can ever be selected. So the degenerate case is O(n) instead of O(1), exhausts an iterator passed by_ref, and perturbs the RNG state.

Details

Added an early return in both methods: sample returns Vec::new() and sample_fill returns 0 when the buffer is empty. No behavior change for amount > 0.

New test test_sample_amount_zero checks that neither method consumes any items (counted via inspect) and that the RNG state is untouched afterwards; the sample half is gated on feature = "alloc". Verified with cargo test --lib seq::iterator on default features and --no-default-features. Existing value-stability tests are unaffected since they use amount > 0.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dhardy]

I'm not keen on this approach since (a) it special-cases amount == 0, leaving the complexity at O(n) for all amount > 0 and (b) some people may rely on the iterator being exhausted and/or on the current permutations to rng (there's a reason choose_stable exists).

We could also consider optimisations (as seen in choose) for amount << n, but then some users may also want stable variants and the additional complexity is hard to justify.

Since the complexity is documented as O(n) the best solution is probably to keep the existing behaviour. (Callers can still special-case amount == 0 if desired.)