Add Iterator::partition_in_place() and is_partitioned()

[cuviper]

partition_in_place() swaps &mut T items in-place to satisfy the
predicate, so all true items precede all false items. This requires
a DoubleEndedIterator so we can search from front and back for items
that need swapping.

is_partitioned() checks whether the predicate is already satisfied.

[rust-highfive]

r? @alexcrichton

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

[Mark-Simulacrum]

inplace_partition personally sounds like a better name to me than partition_mut.

[cuviper]

These are inspired by C++ partition and is_partitioned, spurred by this question about mimicking #include <algorithm>.

This requires a DoubleEndedIterator so we can search from front and back for items that need swapping.

Implementation note: C++ allows partition with only ForwardIt, but they have to use two mutable iterators (cursors) to implement it, which Rust can't really allow. The best I could imagine is keeping a queue of &mut T we've already seen, eligible for swapping, which would require allocation (non-core) and seems generally distasteful.

C++ does talk about bi-directional modes too, which I imagine would work like what I have here.

@Mark-Simulacrum

inplace_partition personally sounds like a better name to me than partition_mut.

I'm open to renaming. I don't think an inplace_ prefix is used anywhere else, but there are examples of ptr::drop_in_place and Alloc::grow_in_place and shrink_in_place.

[Mark-Simulacrum]

Ah -- in that case I think partition_in_place is probably the better name. I thought we had something similar :) I think the _mut suffix is a bit odd, since the iterator must be &mut to even be able to call the method.

[cuviper]

I would have used partition alone if it didn't exist! 🙂 Ours is similar to C++'s partition_copy.

[cuviper]

There's also itertools::partition() -- at a (too-brief) glance I had assumed it was just an IntoIterator wrapper on Iterator::partition, like many of their other free functions, but it actually does the same as my partition_mut, in-place. They return the usize index of the partition split, which seems useful.

I wonder if we might also want an index from is_partitioned, or another method along these lines like find_partition(pred) -> Option<usize>. C++ has partition_point returning an iterator, but we can approximate that already with skip_while(predicate).

[Centril]

_in_place does seem like the better naming.

I would have used partition alone if it didn't exist! 🙂 Ours is similar to C++'s partition_copy.

(That wouldn't have been very appropriate imo as our naming is primarily Haskell based...)

[cuviper]

OK, that's 3 votes for partition_in_place -- changed!

[alexcrichton]

This looks great to me, thanks @cuviper! Could a few more tests be included as well beyond the doc tests?

Otherwise API-wise would it be feasible to return a usize from partition_in_place to indicate the size of one of the partitions? That way for array indexing you could easily split at the index aftewards in theory

[cuviper]

Thanks for the review -- sorry I didn't get back to this yet. I can definitely add more tests, and I think partition_in_place -> usize should be feasible too.

[cuviper]

OK, ready for another review.

[cuviper]

On this, see also #62429.

[alexcrichton]

Looks great to me, thanks @cuviper! r=me with the tracking issue numbers filled in

[cuviper]

Done!

@bors r=alexcrichton

[bors]

📌 Commit 7171c83 has been approved by alexcrichton

[bors]

⌛ Testing commit 7171c83 with merge 0324a2b...