Skip to content

Commit 29d8d40

Browse files
the8472cuviper
andauthored
Apply suggestions from code review
Co-authored-by: Josh Stone <cuviper@gmail.com>
1 parent e561d06 commit 29d8d40

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

library/alloc/src/vec/mod.rs

+6-6
Original file line numberDiff line numberDiff line change
@@ -2796,7 +2796,7 @@ impl<T, I: SliceIndex<[T]>, A: Allocator> IndexMut<I> for Vec<T, A> {
27962796
///
27972797
/// # Allocation behavior
27982798
///
2799-
/// In general `Vec` does not guarantee any particular grow/allocation stategy.
2799+
/// In general `Vec` does not guarantee any particular growth or allocation strategy.
28002800
/// That also applies to this trait impl.
28012801
///
28022802
/// **Note:** This section covers implementation details and is therefore exempt from
@@ -2812,14 +2812,14 @@ impl<T, I: SliceIndex<[T]>, A: Allocator> IndexMut<I> for Vec<T, A> {
28122812
///
28132813
/// The last case warrants some attention. It is an optimization that in many cases reduces peak memory
28142814
/// consumption and improves cache locality. But when a large number of big, short-lived
2815-
/// allocations are created, only a small fraction of their items gets collected, no further use
2816-
/// is made of the spare capacity and the resulting `Vec` is moved into a longer-lived structure
2815+
/// allocations are created, and only a small fraction of their items get collected, no further use
2816+
/// is made of the spare capacity. If the resulting `Vec` is moved into a longer-lived structure,
28172817
/// this can lead to the large allocations having their lifetimes unnecessarily extended which
28182818
/// can result in increased memory footprint.
28192819
///
2820-
/// In cases where this is an issue the excess capacity can be discard with [`Vec::shrink_to()`],
2821-
/// [`Vec::shrink_to_fit()`] or by collecting into [`Box<[T]>`][owned slice] instead which additionally reduces
2822-
/// the size of the longlived struct.
2820+
/// In cases where this is an issue, the excess capacity can be discard with [`Vec::shrink_to()`],
2821+
/// [`Vec::shrink_to_fit()`] or by collecting into [`Box<[T]>`][owned slice] instead, which additionally reduces
2822+
/// the size of the long-lived struct.
28232823
///
28242824
/// [owned slice]: Box
28252825
///

0 commit comments

Comments
 (0)