From 22aecb9c6e894b47935e1c10ece647146c41ded8 Mon Sep 17 00:00:00 2001 From: Sergio Benitez Date: Fri, 16 Feb 2018 17:05:49 -0800 Subject: [PATCH] Clarify contiguity of Vec's elements. --- src/liballoc/vec.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/liballoc/vec.rs b/src/liballoc/vec.rs index 5c7f8ef73217f..39a4d271bd6fe 100644 --- a/src/liballoc/vec.rs +++ b/src/liballoc/vec.rs @@ -231,9 +231,9 @@ use Bound::{Excluded, Included, Unbounded}; /// /// If a `Vec` *has* allocated memory, then the memory it points to is on the heap /// (as defined by the allocator Rust is configured to use by default), and its -/// pointer points to [`len`] initialized elements in order (what you would see -/// if you coerced it to a slice), followed by [`capacity`]` - `[`len`] -/// logically uninitialized elements. +/// pointer points to [`len`] initialized, contiguous elements in order (what +/// you would see if you coerced it to a slice), followed by [`capacity`]` - +/// `[`len`] logically uninitialized, contiguous elements. /// /// `Vec` will never perform a "small optimization" where elements are actually /// stored on the stack for two reasons: @@ -281,8 +281,8 @@ use Bound::{Excluded, Included, Unbounded}; /// not break, however: using `unsafe` code to write to the excess capacity, /// and then increasing the length to match, is always valid. /// -/// `Vec` does not currently guarantee the order in which elements are dropped -/// (the order has changed in the past, and may change again). +/// `Vec` does not currently guarantee the order in which elements are dropped. +/// The order has changed in the past and may change again. /// /// [`vec!`]: ../../std/macro.vec.html /// [`Index`]: ../../std/ops/trait.Index.html