-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Implement VecDeque::retain_mut #91215
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
This comment has been minimized.
This comment has been minimized.
If we add a new variant of retain it would be nice to add a range parameter, it helps in cases where one only wants to work on a sub-section of an vec, e.g. when a callee appended N items then it can be more efficient to only post-filter those items but not the whole vec. |
It seems like a completely different feature. You can't have more parameter in |
Sure, the name could be different, but imo not having the range on In this case |
Please open an issue so you can talk about it with libs team and not flood this PR too much. |
0efd63c
to
ee359c9
Compare
ee359c9
to
0466a12
Compare
@bors r+ rollup |
📌 Commit 0466a12 has been approved by |
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#89642 (environ on macos uses directly libc which has the correct signature.) - rust-lang#90022 (Explain why `Self` is invalid in generic parameters) - rust-lang#90023 (Postpone the evaluation of constant expressions that depend on inference variables) - rust-lang#91215 (Implement VecDeque::retain_mut) - rust-lang#91355 (std: Stabilize the `thread_local_const_init` feature) - rust-lang#91528 (LLVM support .insn directive) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Part of #90829.
In #90772, someone suggested that
retain_mut
should also be implemented onVecDeque
. I think that it follows the same logic (coherency). So first: is it ok? Second: should I create a new feature for it or can we put it into the same one?r? @joshtriplett