From 6600c972e6c74f8a528aecbeaf0a2937ceed8984 Mon Sep 17 00:00:00 2001 From: "orion GONZALEZ (contractor)" Date: Wed, 6 Mar 2024 16:54:42 +0100 Subject: [PATCH] doc: Add better explanation --- compiler/rustc_index/src/vec.rs | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/compiler/rustc_index/src/vec.rs b/compiler/rustc_index/src/vec.rs index d876174e620..88298150a79 100644 --- a/compiler/rustc_index/src/vec.rs +++ b/compiler/rustc_index/src/vec.rs @@ -12,7 +12,24 @@ use crate::{Idx, IndexSlice}; /// An owned contiguous collection of `T`s, indexed by `I` rather than by `usize`. -/// Its purpose is to avoid mixing indexes. +/// +/// ## Why use this instead of a `Vec`? +/// +/// An `IndexVec` allows element access only via a specific associated index type, meaning that +/// trying to use the wrong index type (possibly accessing an invalid element) will fail at +/// compile time. +/// +/// It also documents what the index is indexing: in a `HashMap` it's not +/// immediately clear what the `usize` means, while a `HashMap` makes it obvious. +/// +/// ```compile_fail +/// use rustc_index::{Idx, IndexVec}; +/// +/// fn f(vec1: IndexVec, idx1: I1, idx2: I2) { +/// &vec1[idx1]; // Ok +/// &vec1[idx2]; // Compile error! +/// } +/// ``` /// /// While it's possible to use `u32` or `usize` directly for `I`, /// you almost certainly want to use a [`newtype_index!`]-generated type instead.