Challenge 2: A Generic Pair<T, U> Struct — Possible Solution
====================================================================

struct Pair<T, U> {
    first: T,
    second: U,
}

impl<T: std::fmt::Display, U: std::fmt::Display> Pair<T, U> {
    fn describe(&self) -> String {
        format!("({}, {})", self.first, self.second)
    }
}

fn main() {
    let p = Pair { first: 42, second: "hello" };
    println!("{}", p.describe()); // (42, hello)
}

WHY THIS WORKS AS AN ANSWER
------------------------------
Pair<T, U> uses TWO type parameters, exactly this chapter's guidance
for when fields genuinely need to differ in type — first: T and
second: U are allowed to be entirely unrelated types (here, an i32
and a &str), which a single shared T (as in the chapter's own Point<T>
example) could not express.

WHY THE BOUND GOES ON THE impl BLOCK, NOT THE STRUCT DEFINITION:
struct Pair<T, U> { ... } by itself makes NO claim about what T and U
can DO — it only describes the SHAPE of the data (two fields of two
possibly-different types). Any Pair<T, U> can be constructed for any
T and U at all, with no restrictions, which is exactly what should be
possible — creating a Pair doesn't inherently require being able to
Display anything.

The Display requirement only becomes necessary once describe() is
called, since ITS body specifically uses {} formatting (which requires
Display) on self.first and self.second. Attaching the bound to the
impl block (impl<T: Display, U: Display> Pair<T, U>) means the bound
only applies to THIS particular impl block's methods, not to Pair
itself — so a Pair<T, U> holding non-Display types can still be
constructed and used for anything that doesn't call describe(), while
only actually calling describe() requires both T and U to satisfy
Display. Putting the bound on the struct definition instead would
incorrectly restrict EVERY use of Pair, even ones that never touch
describe() at all.