Repository navigation
Tracking Issue for Vec::split_at_spare_mut #81944
Description
Feature gate: #![feature(vec_split_at_spare)]
This is a tracking issue for Vec::split_at_spare_mut, which is used as the basis for a few methods internally to give a slice pointing to the initialized portion of the Vec and a slice of MaybeUninit pointing to the uninitialized portion.
Public API
impl<T, A: Allocator> Vec<T, A> {
pub fn split_at_spare_mut(&mut self) -> (&mut [T], &mut [MaybeUninit<T>]) {}
}Steps / History
- Implementation: Make Vec::split_at_spare_mut public #81687
- Final commenting period (FCP)
- Stabilization PR
Unresolved Questions
- Should we consider changing the name?
split_at_spare_mutdoesn't seem like an intuitive name - Should we deprecate
Vec::spare_capacity_mut? Any usecase ofVec::spare_capacity_mutcan be replaced withVec::split_at_spare_mut(but not vise-versa):
edit:spare_capacity_muthas been stabilised now in Stabilize vec_spare_capacity #93016 so deprecating it is probably not an option
Reacted by Daniel Henry-Mantilla, Aaron Bies, Jalil David Salamé Messina, EvianZhang and Gabriel Bjørnager Jensen
Reacted by Gabriel Bjørnager Jensen
Activity
Amanieu commentedon Feb 10, 2021
Interesting! I personally use
spare_capacity_mutin my code to read into uninitialized buffers. I feel that it may be worth keeping it as a convenience method, but then again it is quite rarely used so I don't mind having to write an extra.1.WaffleLapkin commentedon Feb 10, 2021
Hm, why there are no unresolved questions yet? It doesn't seem that the questions from the implementation PR were resolved:
split_at_spare_mutdoesn't seem like an intuitive nameVec::spare_capacity_mut? Any usecase ofVec::spare_capacity_mutcan be replaced withVec::split_at_spare_mut(but not vise-versa)KodrAus commentedon Feb 21, 2021
@WaffleLapkin I just missed those questions that came up after the PR approval is all 🙂 They're in the tracking issue now.
RalfJung commentedon Feb 21, 2021
That is not true:
split_at_spare_mutcreates mutable references to the entire initialized part of the vector and will thus invalidate any preexisting pointers.spare_capacity_mut, if it is implemented carefully (which I have not checked) could be made to not invalidate existing pointers into the initialized part of the vector.WaffleLapkin commentedon Feb 21, 2021
@RalfJung ohhh. I haven't thought of this. Then I guess the question "do we need both?" is resolved: yes.
Current implementation just calls
self.split_at_spare_mut().1😅RalfJung commentedon Feb 21, 2021
Well, that doesn't count as "careful" I guess. ;)
WaffleLapkin commentedon Feb 21, 2021
I guess so 😅
I'll try to make the implementation more careful (revert it?) and make a PR :)
Rollup merge of rust-lang#82564 - WaffleLapkin:revert_spare_mut, r=Ra…
Rollup merge of rust-lang#82564 - WaffleLapkin:revert_spare_mut, r=Ra…
Rollup merge of rust-lang#82564 - WaffleLapkin:revert_spare_mut, r=Ra…
saethlin commentedon Jan 4, 2022
Oops, what I commented here is far more relevant to
Vec::spare_capacity_mut, comment moved: #75017 (comment)ast-ral commentedon Apr 23, 2026
Apologies if this is out of place, but it might be good to have a analogous
leak_and_split_spare_capacity_mutmethod, since leak doesn't shrink the vector before returning and there's no (safe) way to get access to the unused capacity that I'm aware of.