Change:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses 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. [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- Initial implementation ()
FWIW, here is a full-featured API provided by an external crate:
I wonder how this API relates to . It would be great if there was some safe API that wrapped around the use of to access a 's spare capacity, then updated based on the s .
Maybe we should follow that example and generalize to return ?
has implemented that, albeit as a private function. Sounds like a good idea to me.
Since exists now I think is redundant.
That's not actually true due to pointer invalidation, see and
I think it would be better to have this feature sooner rather than later. I'm starting to notice instances where people are doing things that are probably or definitely UB because they want this functionality. So I think this API falls squarely into the standard library's mission to provide pre-built and correct implementations of things that are subtle or difficult to get right.   (originally posted on but per Ralf's comments there, it is probably better to have this method for the above use cases)
I agree. I've been using this in my code and found it to be very useful. Even though is more general, I've never had a need for it and I feel that is useful on its own. The API being stabilized is: merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
while waiting for this feature to be stabilized, you should suggest that and use one of the convenience methods in:
:bell: This is now entering its final comment period, as per the . :bell:
Ralf mentioned this on , mostly rewording with my own opinion: I would prefer not to recommend that function, because even if you just want access to the spare region, under SB, these interfaces invalidate all pointers to the initialized region. I think that's too much of a footgun for codebases where people are already writing code that is rejected by Miri.
I wonder how many people do keep outstanding pointers to the initialized part while toying with the extra part 's implementation is already better than their 0-elems slices that get -ly converted into non-empty slices (and currently better than the stdlib one since it doesn't involve a 12-week delay for stable Rust). Anyhow, I've just released a new version () with a dedicated adapter: , for extra good measure.
To be clear, my concern is that the splitting interfaces are adding a landmine for the future. If I'm sending someone a PR I'll make sure it passes Miri at the time, but that's a hard condition to maintain. Especially because the two aforementioned codebases have dependencies that do int-ptr casts, an operation that Miri just doesn't understand at the moment, so it would be hard to advocate Miri in CI.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(vec_spare_capacity)] /// </del> /// // Allocate vector big enough for 10 elements. /// let mut v = Vec::with_capacity(10); ///

/// /// assert_eq!(&v, &[0, 1, 2]); /// ``` <del> #[unstable(feature = "vec_spare_capacity", issue = "75017")] </del> <ins> #[stable(feature = "vec_spare_capacity", since = "1.60.0")] </ins> #[inline] pub fn spare_capacity_mut(&mut self) -> &mut [MaybeUninit<T>] { // Note:

#![feature(iter_advance_by)] #![feature(slice_group_by)] #![feature(slice_partition_dedup)] <del> #![feature(vec_spare_capacity)] </del> #![feature(string_remove_matches)] #![feature(const_btree_new)] #![feature(const_default_impls)]

/// ``` /// /// ``` <del> /// #![feature(maybe_uninit_write_slice, vec_spare_capacity)] </del> <ins> /// #![feature(maybe_uninit_write_slice)] </ins> /// use std::mem::MaybeUninit; /// /// let mut vec = Vec::with_capacity(32);

#![feature(unboxed_closures)] #![feature(unwrap_infallible)] #![feature(vec_into_raw_parts)] <del> #![feature(vec_spare_capacity)] </del> // NB: the above list is sorted to minimize merge conflicts. #![default_lib_allocator]

<del> Subproject commit 2adc17a5442614dbe34626fdd9b32de7c07b8086 </del> <ins> Subproject commit 1d5d0e8b0e3134dc781adb98057e38ffdf200df2 </ins>