Repository navigation
Open
Labels
A-btreeArea: `std::collections::{BTreeMap, BTreeSet}`Area: `std::collections::{BTreeMap, BTreeSet}`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 RFC
Description
This is a tracking issue for a range-based drain method on BTreeMap and BTreeSet, similar to the one in Vec.
The feature gate for the issue is #![feature(btree_drain)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Implement the main method
- Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- Is plain
drainthe right name for a range-based function? It's equivalent toVec::drainif you consider aVec<T>to be aBTreeMap<usize, T>with consecutive keys. It's not equivalent to theHashMap::drain()without argument, andBTreeMap::drain(..)doesn't compile without a type annotation if the key type has additionalBorrowimplementations, whereasVec::drain(..)is always a simple way to drain everything. - An efficient implementation of draining implies most of the drained key-value pairs are in entirely preserved (and not even visited) subtrees. Therefore, the return value can be relatively easily adapted to obtain a range-based method much like
split_off. Is it OK to addsplit_off_rangealong the way?
Implementation history
- First real shot: BTree: add drain methods #81075
- Early attempt at argumentless
drain: BTreeMap/BTreeSet drain & retain #66747
Reacted by Toshiki Kataoka, Matthew Little, Poliorcetics, Guillermo Lloret Talavera, Rostyslav Lesovyi, kk, Rot127, Thomas B, Lucas Baizer, Marcin Anforowicz and 4 more
Metadata
Metadata
Assignees
Labels
A-btreeArea: `std::collections::{BTreeMap, BTreeSet}`Area: `std::collections::{BTreeMap, BTreeSet}`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 RFC
Activity
ssomers commentedon Jan 16, 2021
@rustbot modify labels: +S-A-collections +S-B-unstable +S-C-tracking-issue +S-Libs-Tracked +S-T-libs
JohnTitor commentedon Jul 21, 2022
@ssomers The implementation PR has been closed, do you want to follow up or could we close this tracking issue for now?
Ten0 commentedon Dec 16, 2024
It's definitely the function name I was looking for given the one on
Vec.It also enabled me to quickly find this issue.
I may be wrong but my guess would be he got tired of rebasing 1700 loc every month for a year and a half, without any review for a year.
ssomers commentedon Dec 18, 2024
Also, there has not been any activity on any of the library issues (discussions) I got involved in. As if Rust got abandoned. But the news maintains the opposite. I don't understand.
Nobody suggested to me they wanted a drain, I didn't need it for anything myself, I just saw it as a gap in the collection API, and assumed it was due to the challenge to implement it efficiently.