Code change:
} } <ins> /// Appends an element if there is sufficient spare capacity, otherwise an error is returned /// with the element. /// /// Unlike [`push`] this method will not reallocate when there's insufficient capacity. /// The caller should use [`reserve`] or [`try_reserve`] to ensure that there is enough capacity. /// /// [`push`]: Vec::push /// [`reserve`]: Vec::reserve /// [`try_reserve`]: Vec::try_reserve /// /// # Examples /// /// A manual, panic-free alternative to [`FromIterator`]: /// /// ``` /// #![feature(vec_push_within_capacity)] /// /// use std::collections::TryReserveError; /// fn from_iter_fallible<T>(iter: impl Iterator<Item=T>) -> Result<Vec<T>, TryReserveError> { ///     let mut vec = Vec::new(); ///     for value in iter { ///         if let Err(value) = vec.push_within_capacity(value) { ///             vec.try_reserve(1)?; ///             // this cannot fail, the previous line either returned or added at least 1 free slot ///             let _ = vec.push_within_capacity(value); ///         } ///     } ///     Ok(vec) /// } /// assert_eq!(from_iter_fallible(0..100), Ok(Vec::from_iter(0..100))); /// ``` #[inline] #[unstable(feature = "vec_push_within_capacity", issue = "100486")] pub fn push_within_capacity(&mut self, value: T) -> Result<(), T> { if self.len == self.buf.capacity() { return Err(value); } unsafe { let end = self.as_mut_ptr().add(self.len); ptr::write(end, value); self.len += 1; } Ok(()) } </ins> /// Removes the last element from a vector and returns it, or [`None`] if it /// is empty. ///

Related discussion:
text: This enhancement suggestion looks a bit silly to me, but I think it's worth asking for an opinion in this bug tracker. I think this is a reasonable usage pattern of and . I've used it with a larger SomeData to avoid both an useless initialization and the use of that in those cases is slightly slower, the disadvantage is that this code contains and it's a bit fiddly: An API that removes the unsafety could be: is similar to , but it doesn't include any growing strategy (and doesn't include such growing/realloc code in the binary), so it just uses the capacity. If the capacity isn't enough it panics (just like the first code panics if the capacity is finished at ).
label C-enhancement
label -C-enhancement C-feature-request
It might be better to return a instead to let the user handle the failure case.
An extra note. Currently on this code: I think LLVM12 isn't able to see that code will never realloc and doesn't need a bound test:
The naive implementation of already optimizes out the reallocation case with . Since (parts of) the reallocation code is inlined into , this would give smaller code size (). Here is a use case that I encounter fairly frequently: I want to construct a , so I preallocate one and push elements into it. However, if there is an off-by-one error in the preallocation, then it would reallocate every time. Having a function (followed by unwrap) would help catch these errors.
I suggest creating a fixed-capacity type wrapper instead, so that it can also be used with and many more methods without realloc code bloat.
I suggest creating a fixed-capacity Vec type wrapper instead, so that it can also be used with Extend and many more methods without realloc code bloat. A question: such wrapper doesn't cause bloat itself?
No, I don't think it'd be much different from deref that gives you the as a slice.
What do you envision to do when the vector runs out of space?
Panic. I also hope that the wrapper type with a fixed-size storage would be easier for optimizer to reason about (similarly how taking a slice of a vec before a loop helps remove bounds checks in the loop). If the optimizer is able to remove capacity checks, then failure handling code doesn't matter, because it will be optimized out too.