Repository navigation
Tracking Issue for Vec::split_at_spare_mut #81944
Description
Activity
- addedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]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
on Feb 9, 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.Hm, why there are no unresolved questions yet? It doesn't seem that the questions from the implementation PR were resolved:
- 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)
- Should we consider changing the name?
@WaffleLapkin I just missed those questions that came up after the PR approval is all 🙂 They're in the tracking issue now.
Reacted by waffleAny usecase of Vec::spare_capacity_mut can be replaced with Vec::split_at_spare_mut (but not vise-versa)
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.Reacted by Martin Habovštiak@RalfJung ohhh. I haven't thought of this. Then I guess the question "do we need both?" is resolved: yes.
if it is implemented carefully
Current implementation just calls
self.split_at_spare_mut().1😅Current implementation just calls self.split_at_spare_mut().1
Well, that doesn't count as "careful" I guess. ;)
I guess so 😅
I'll try to make the implementation more careful (revert it?) and make a PR :)
Reacted by Ralf JungOops, what I commented here is far more relevant to
Vec::spare_capacity_mut, comment moved: #75017 (comment)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.- addedT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.and removedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Aug 12, 2026
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 theVecand a slice ofMaybeUninitpointing to the uninitialized portion.Public API
Steps / History
Unresolved Questions
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):edit:
spare_capacity_muthas been stabilised now in Stabilize vec_spare_capacity #93016 so deprecating it is probably not an option