Repository navigation
Tracking issue for slice_partition_at_index #55300
Description
Activity
Just for the record, if someone needs this functionality right now, the order_stat crate provides an implementation of the Floyd-Rivest selection algorithm.
Reacted by IGI-111, Pavel Krajcevski, Stanislav Tkach and Eric Shimizu Karbstein- added a commit that references this issue
on Jan 23, 2019 - addedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.
on Jan 27, 2019 - added a commit that references this issue
on Mar 11, 2019 A thought: since we have
sortandsort_unstable, should the method that got implemented bepartition_unstable_at_indexinstead? Though I suppose there's no good stable way to do it...Reacted by Pavel KrajcevskiHi @Mokosha , is this expected to be stabilized eventually?
- 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 RFCand removedC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.
on Sep 2, 2019 - changed the title
[-]Feature Request: analog of C++'s std::nth_element for rust slices.[/-][+]Tracking issue for slice_partition_at_index[/+]on Sep 2, 2019 34 remaining items
@Amanieu I'm happy to make the PR changing the name and stabilizing the issue, but I have a question: If we change the name, this will be breaking for anyone who's been using the current name. It this acceptable, or is there an aliasing step that will preserve behavior for those using the feature flag?
@jagill It's nightly so it's allowed, but to make it a bit easier on nightly users it's generally preferable to to stabilize it under a different feature gate name so the old method can be left there for a month or two before being removing.
- addedfinished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.to-announceAnnounce this issue on triage meetingAnnounce this issue on triage meetingand removedfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
on Oct 9, 2020 The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
The RFC will be merged soon.
- added a commit that references this issue
on Oct 12, 2020 - added a commit that references this issue
on Oct 13, 2020 - added a commit that references this issue
on Oct 13, 2020 - removedto-announceAnnounce this issue on triage meetingAnnounce this issue on triage meeting
on Oct 15, 2020 I've opened #93480 to remove the deprecated and unstable
partition_at_index_*functions that were added to ease the transition to the stable feature.
This is the tracking bug for the discussion outlined in rust-lang/rfcs#1470.
I'm working on implementing this in the
libstd, and will add it as an unstable feature pending resolution of any comments that may arise in this thread. I plan to add comprehensive testing as well.