Challenge 2: Fixed Array vs. Vec for a Known Size — Possible Solution ==================================================================== [i32; 100] IS THE BETTER DEFAULT CHOICE for a function that only ever needs exactly 100 known-at-compile-time integers, for reasons directly tied to this chapter's stack-vs-heap discussion. WHY: [i32; 100] is allocated entirely on the STACK — per this chapter's explanation, stack allocation is essentially just moving a pointer (the stack pointer), an extremely fast, allocator-free operation. Vec, even with exactly 100 elements, still allocates its backing storage on the HEAP — going through the real allocator, with genuine bookkeeping overhead, purely because Vec is DESIGNED to support a size that might change at runtime, a capability this scenario explicitly doesn't need at all (the size is fixed and known at compile time). Beyond the allocation cost itself, a stack array also avoids an extra level of INDIRECTION that Vec's heap-pointer-based design requires — accessing an element of a stack array can be a more direct memory access, without first following a pointer to wherever the heap allocation happens to live. WHEN Vec WOULD GENUINELY BE THE RIGHT CHOICE INSTEAD: if the actual number of elements weren't known until runtime (e.g. depending on user input, a file's contents, or some other value not fixed at compile time), or if the collection genuinely needed to grow or shrink during the program's execution — situations this chapter's own general guidance ("heap types when size is genuinely unknown at compile time or ownership needs to move around") already covers. For a case that's fixed at exactly 100 elements, known at compile time, with no need to ever change, the fixed-size stack array is strictly cheaper with no real downside.