From 2cddfa55d35df8724e6b71bff699d13db57081b0 Mon Sep 17 00:00:00 2001 From: the8472 Date: Tue, 30 Jan 2024 22:36:29 +0100 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Josh Stone --- library/alloc/src/vec/mod.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/library/alloc/src/vec/mod.rs b/library/alloc/src/vec/mod.rs index 941cc0239d2b8..b3e5ecc924071 100644 --- a/library/alloc/src/vec/mod.rs +++ b/library/alloc/src/vec/mod.rs @@ -2798,14 +2798,14 @@ impl, A: Allocator> IndexMut for Vec { /// depending on the supplied iterator: /// /// * preallocate based on [`Iterator::size_hint()`] -/// * and panic if the number of items is not outside the provided lower/upper bounds +/// * and panic if the number of items is outside the provided lower/upper bounds /// * use an amortized growth strategy similar to `pushing` one item at a time /// * perform the iteration in-place on the original allocation backing the iterator /// /// The last case warrants some attention. It is an optimization that in many cases reduces peak memory /// consumption and improves cache locality. But when big, short-lived allocations are created, -/// only a small fraction of their items gets collected, no further use is made of the spare capacity -/// and the resulting `Vec` is moved into a longer-lived structure this can lead to the large +/// only a small fraction of their items get collected, no further use is made of the spare capacity +/// and the resulting `Vec` is moved into a longer-lived structure, then this can lead to the large /// allocations having their lifetimes unnecessarily extended which can result in increased memory /// footprint. ///