Challenge 1: A Container Trait with an Associated Type — Possible Solution
====================================================================

trait Container {
    type Item;
    fn get(&self, index: usize) -> Option<&Self::Item>;
}

struct StringBag {
    items: Vec<String>,
}

impl Container for StringBag {
    type Item = String;

    fn get(&self, index: usize) -> Option<&String> {
        self.items.get(index)
    }
}

fn main() {
    let bag = StringBag { items: vec![String::from("a"), String::from("b")] };
    println!("{:?}", bag.get(0)); // Some("a")
    println!("{:?}", bag.get(5)); // None
}

WHY THIS WORKS AS AN ANSWER
------------------------------
The Container trait declares type Item as a placeholder, exactly this
chapter's associated-type pattern — the trait itself doesn't know or
care what Item will be; it just requires that get() return an
Option<&Self::Item>, referencing whatever type Item ends up being for
each specific implementor.

StringBag's impl block fills in the placeholder concretely with type
Item = String, tying Item to String specifically for THIS
implementation — this is the "one specific type per implementation"
property this chapter contrasted against a generic trait parameter
approach.

get()'s implementation simply delegates to Vec's own built-in .get(),
which already returns an Option<&String> for a Vec<String> — matching
Self::Item (now known to be String) exactly, so no further conversion
is needed. Returning None for an out-of-bounds index (rather than
panicking) mirrors the same safe, Option-based "might not exist"
handling used throughout Course 1's own material on Option<T>.