Skip to content

Commit 5c11392

Browse files
committed
Redo the docs for Vec::set_len
Inspired by the recent conversation on IRLO.
1 parent aef4dbf commit 5c11392

File tree

1 file changed

+53
-27
lines changed

1 file changed

+53
-27
lines changed

src/liballoc/vec.rs

Lines changed: 53 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -748,28 +748,64 @@ impl<T> Vec<T> {
748748
self
749749
}
750750

751-
/// Sets the length of a vector.
751+
/// Forces the length of a vector to a particular value.
752752
///
753-
/// This will explicitly set the size of the vector, without actually
754-
/// modifying its buffers, so it is up to the caller to ensure that the
755-
/// vector is actually the specified size.
753+
/// This is a low-level operation that maintains none of the normal
754+
/// invariants of the type. Normally changing the length of a `Vec`
755+
/// is done using one of the safe operations instead, such as
756+
/// [`truncate`], [`resize`], [`extend`], or [`clear`].
756757
///
757-
/// # Examples
758+
/// [`truncate`]: #method.truncate
759+
/// [`resize`]: #method.resize
760+
/// [`extend`]: #method.extend-1
761+
/// [`clear`]: #method.clear
758762
///
759-
/// ```
760-
/// use std::ptr;
763+
/// # Safety
761764
///
762-
/// let mut vec = vec!['r', 'u', 's', 't'];
765+
/// - `new_len` must be less than or equal to `capacity()`.
766+
/// - All elements between past the previous end up to the `new_len`
767+
/// must be initialized.
763768
///
764-
/// unsafe {
765-
/// ptr::drop_in_place(&mut vec[3]);
766-
/// vec.set_len(3);
769+
/// # Examples
770+
///
771+
/// This method can be useful for situations in which the `Vec` is
772+
/// serving as a buffer for other code, particularly over FFI:
773+
///
774+
/// ```no_run
775+
/// # #![allow(dead_code)]
776+
/// # // This is just a minimal skeleton for the doc example;
777+
/// # // don't use this as a starting point for a real library.
778+
/// # pub struct StreamWrapper { strm: *mut std::ffi::c_void }
779+
/// # const Z_OK: i32 = 0;
780+
/// # extern "C" {
781+
/// # fn deflateGetDictionary(
782+
/// # strm: *mut std::ffi::c_void,
783+
/// # dictionary: *mut u8,
784+
/// # dictLength: *mut usize,
785+
/// # ) -> i32;
786+
/// # }
787+
/// # impl StreamWrapper {
788+
/// pub fn get_dictionary(&self) -> Option<Vec<u8>> {
789+
/// // Per the docs, "32768 bytes is always enough".
790+
/// let mut dict = Vec::with_capacity(32_768);
791+
/// let mut dict_length = 0;
792+
/// unsafe {
793+
/// // Make the FFI call...
794+
/// let r = deflateGetDictionary(self.strm, dict.as_mut_ptr(), &mut dict_length);
795+
/// if r == Z_OK {
796+
/// // ...and update the length to what was initialized.
797+
/// dict.set_len(dict_length);
798+
/// Some(dict)
799+
/// } else {
800+
/// None
801+
/// }
802+
/// }
767803
/// }
768-
/// assert_eq!(vec, ['r', 'u', 's']);
804+
/// # }
769805
/// ```
770806
///
771-
/// In this example, there is a memory leak since the memory locations
772-
/// owned by the inner vectors were not freed prior to the `set_len` call:
807+
/// While the following example is sound, there is a memory leak since
808+
/// the inner vectors were not freed prior to the `set_len` call:
773809
///
774810
/// ```
775811
/// let mut vec = vec![vec![1, 0, 0],
@@ -780,21 +816,11 @@ impl<T> Vec<T> {
780816
/// }
781817
/// ```
782818
///
783-
/// In this example, the vector gets expanded from zero to four items
784-
/// without any memory allocations occurring, resulting in vector
785-
/// values of unallocated memory:
786-
///
787-
/// ```
788-
/// let mut vec: Vec<char> = Vec::new();
789-
///
790-
/// unsafe {
791-
/// vec.set_len(4);
792-
/// }
793-
/// ```
819+
/// (Instead, one would normally use [`clear`] in this situation.)
794820
#[inline]
795821
#[stable(feature = "rust1", since = "1.0.0")]
796-
pub unsafe fn set_len(&mut self, len: usize) {
797-
self.len = len;
822+
pub unsafe fn set_len(&mut self, new_len: usize) {
823+
self.len = new_len;
798824
}
799825

800826
/// Removes an element from the vector and returns it.

0 commit comments

Comments
 (0)