@@ -253,26 +253,6 @@ mod spec_extend;
253253/// can be slow. For this reason, it is recommended to use [`Vec::with_capacity`]
254254/// whenever possible to specify how big the vector is expected to get.
255255///
256- /// A vector containing the elements `'a'` and `'b'` with capacity 4 can be
257- /// visualized as:
258- ///
259- /// ```text
260- /// Stack ptr len capacity
261- /// /Heap +--------+--------+--------+
262- /// | 0x0123 | 2 | 4 |
263- /// +--------+--------+--------+
264- /// |
265- /// v
266- /// Heap +--------+--------+--------+--------+
267- /// | 'a' | 'b' | uninit | uninit |
268- /// +--------+--------+--------+--------+
269- /// ```
270- ///
271- /// - **uninit** represents memory that is not initialized, see [`MaybeUninit`].
272- /// - Note: the ABI is not stable and `Vec` makes no guarantees about its memory
273- /// layout (including the order of fields). See [the section about
274- /// guarantees](#guarantees).
275- ///
276256/// # Guarantees
277257///
278258/// Due to its incredibly fundamental nature, `Vec` makes a lot of guarantees
@@ -305,6 +285,28 @@ mod spec_extend;
305285/// you would see if you coerced it to a slice), followed by [`capacity`]` -
306286/// `[`len`] logically uninitialized, contiguous elements.
307287///
288+ /// A vector containing the elements `'a'` and `'b'` with capacity 4 can be
289+ /// visualized as below. The top part is the `Vec` struct, it contains a
290+ /// pointer to the head of the allocation in the heap, length and capacity.
291+ /// The bottom part is the allocation on the heap, a contiguous memory block.
292+ ///
293+ /// ```text
294+ /// ptr len capacity
295+ /// +--------+--------+--------+
296+ /// | 0x0123 | 2 | 4 |
297+ /// +--------+--------+--------+
298+ /// |
299+ /// v
300+ /// Heap +--------+--------+--------+--------+
301+ /// | 'a' | 'b' | uninit | uninit |
302+ /// +--------+--------+--------+--------+
303+ /// ```
304+ ///
305+ /// - **uninit** represents memory that is not initialized, see [`MaybeUninit`].
306+ /// - Note: the ABI is not stable and `Vec` makes no guarantees about its memory
307+ /// layout (including the order of fields). See [the section about
308+ /// guarantees](#guarantees).
309+ ///
308310/// `Vec` will never perform a "small optimization" where elements are actually
309311/// stored on the stack for two reasons:
310312///
0 commit comments