-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add Vec::retain_mut
#83218
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
Add Vec::retain_mut
#83218
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
I think the interaction with drain_filter and the (to me) very similar API surface is interesting here; I'm not sure whether one is definitively easier than the other to stabilize, and while both are unstable it feels like drain_filter already gives basically the same API? (Potentially at higher cost but hopefully not...) r? @m-ou-se for T-libs member approval of unstable API |
@jonas-schievink I'd like to hear your opinion on the (unstable) #![feature(drain_filter)]
let mut vec = vec![1, 2, 3, 4];
vec.drain_filter(|x| if *x > 3 {
true
} else {
*x += 1;
false
});
assert_eq!(vec, [2, 3, 4]); That function is still unstable, so if there is a specific reason you don't consider it suitable for this use case, maybe we can come up with a way to change it such that it would suffice. |
Yeah, |
@jonas-schievink So, should we close this? Or is there a reason you'd still prefer |
Yeah, I guess let's close |
I would love to have |
Even if you don't need the removed items, drain_filter still provides a near-equivalent API, so it's not clear that it's any worse to me. Having two APIs doing the same thing with slightly different interfaces seems worse, though. That said, I think just a new PR here is fine, if you want to discuss that. |
Well, it would be coherent with the rest. For example we have |
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc `@m-ou-se` `@jonas-schievink` `@Mark-Simulacrum`
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc ``@m-ou-se`` ``@jonas-schievink`` ``@Mark-Simulacrum``
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc ```@m-ou-se``` ```@jonas-schievink``` ```@Mark-Simulacrum```
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc ````@m-ou-se```` ````@jonas-schievink```` ````@Mark-Simulacrum````
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc `````@m-ou-se````` `````@jonas-schievink````` `````@Mark-Simulacrum`````
…shtriplett Add Vec::retain_mut This is to continue the discussion started in rust-lang#83218. Original comment was: > Take 2 of rust-lang#34265, since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it. cc ``````@m-ou-se`````` ``````@jonas-schievink`````` ``````@Mark-Simulacrum``````
Take 2 of #34265, since I needed this today.