Repository navigation
Tracking issue for Iterator::is_partitioned #62544
Description
Activity
- addedB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Jul 9, 2019 - addedA-iteratorsArea: IteratorsArea: IteratorsI-libs-radarLibs issues that are tracked on the team's radar.Libs issues that are tracked on the team's radar.
on Jul 30, 2020 Is there anything blocking this from stabiilization?
No blocker that I know of. There's some question about the related
partition_in_place, butis_partitionedis straightforward.Comments from the stabilization PR:
I've looked at the various linked issues but didn't see any motivating use cases for this routine.
Thinking a bit more about this, I suppose that pretty much all use cases of this function are also covered by
is_sorted_by_key.I've added this as an unresolved question above.
(arrived here thanks to an initially unrelated curiosity re:
iterator::partition(specifically, that it only provides binary partitions))About use cases: one could be to aid (perhaps semi-automated) porting of existing C++ code that uses
stdlibpartition(which maps topartition_in_placein Rust, as I understand it?) in combination withstdlibis_partitioned.I'm a very small Rustacean so I don't know if I understand correctly, but it does seem like all use cases for
is_partitionedcould theoretically be translated to an implementation in terms ofis_sorted_by_key-- but that doing that could require careful sort order / partition function handling, and perhaps more care than automated porting tools could achieve easily / performantly. Basically I think they'd tend to rewrite it as a a check foris_sorted_by ( negation ( partition_func ) )(because the left-side partition is thetruevalues).Current implementation notes:
is_sorted_by_keyperforms a (lazy)mapacross the iterator whereas the currentis_partitionedimplementation short-circuits by applyingalluntil failure, and thenanyfor remaining elements. Those seem to both have O(n) worst-case?Can this be extended to return an
Option<usize>that would beSome(partition_point)if it is partitioned andNoneif it's not?I conducted some testing, and the current implementation (which is quite neat in my opinion),
iter.all(predicate) || !iter.any(predicate), is about 2.5 times faster than the implementation usingiter.is_sorted_by_key(|x| !predicate(x)). I conducted this testing in response to @jayaddison's comment, although I must admit that I somewhat lost track of the original purpose in the process.While I feel somewhat indifferent towards the
is_partitioned()function, I would be interested in seeing something similar to what @siebenHeaven suggests implemented. However, I believe the function should be named differently; perhapsfind_partition_indexwould be more suitable?Is there a similar suggestion already in progress? If so, could you assist me in locating it? If not, would you be able to point me to how I can create a new one?
@Areczek94 Did you mean to give your opinion on "Do we want this function at all?" Seems that your comment is exactly the same as the original post but with that option marked on.
For future reference, you can just say that you think that this function is worth it, and make your argument after thinking about it for a while. No need to copy-paste the original post.
- addedT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.and removedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Aug 12, 2026
feature = "iter_is_partitioned"ref: #62278
Unresolved questions
is_sorted_by_keyalready cover all use cases?