Skip to content

Commit 3cdc3b7

Browse files
authored
Rollup merge of #126118 - jan-ferdinand:docs_for_vec_set_len, r=the8472
docs: Mention `spare_capacity_mut()` in `Vec::set_len` I recently went down a small rabbit hole when trying to identify safe use of `Vec::set_len`. The solution was `Vec::spare_capacity_mut`. I think the docs on `Vec::set_len` benefit from mentioning this method. A possible counter-argument could be that the [clippy lint `uninit_vec`](https://rust-lang.github.io/rust-clippy/master/index.html#/uninit_vec) already nudges people in the right direction. However, I think a working example on `Vec::set_len` is still beneficial. Happy to hear your thoughts on the matter. 😊
2 parents 214587c + 07ba1fd commit 3cdc3b7

File tree

1 file changed

+6
-1
lines changed

1 file changed

+6
-1
lines changed

library/alloc/src/vec/mod.rs

+6-1
Original file line numberDiff line numberDiff line change
@@ -1824,7 +1824,10 @@ impl<T, A: Allocator> Vec<T, A> {
18241824
///
18251825
/// # Examples
18261826
///
1827-
/// This method can be useful for situations in which the vector
1827+
/// See [`spare_capacity_mut()`] for an example with safe
1828+
/// initialization of capacity elements and use of this method.
1829+
///
1830+
/// `set_len()` can be useful for situations in which the vector
18281831
/// is serving as a buffer for other code, particularly over FFI:
18291832
///
18301833
/// ```no_run
@@ -1884,6 +1887,8 @@ impl<T, A: Allocator> Vec<T, A> {
18841887
///
18851888
/// Normally, here, one would use [`clear`] instead to correctly drop
18861889
/// the contents and thus not leak memory.
1890+
///
1891+
/// [`spare_capacity_mut()`]: Vec::spare_capacity_mut
18871892
#[inline]
18881893
#[stable(feature = "rust1", since = "1.0.0")]
18891894
pub unsafe fn set_len(&mut self, new_len: usize) {

0 commit comments

Comments
 (0)