Challenge 2: impl Trait's Limit — Possible Solution
====================================================================

fn print_description(item: &impl Describable) {
    println!("{}", item.describe());
}

WHY THIS CAN'T COMPARE TWO ITEMS OF POTENTIALLY DIFFERENT TYPES
------------------------------
`impl Describable` used twice as separate parameter types — e.g. in a
hypothetical fn compare(a: &impl Describable, b: &impl Describable) —
does NOT require a and b to be the same concrete type. Each `impl
Trait` parameter is independently "some type implementing Describable"
— a could be a Book while b is a Widget, and the function signature
alone provides no way to require otherwise. There is genuinely no
syntax using impl Trait sugar that can express "these two parameters
must be the identical concrete type," because each `impl Trait`
occurrence is resolved independently.

THE SYNTAX CHANGE NEEDED: replacing both impl Trait occurrences with a
single shared generic parameter and a trait bound, exactly this
chapter's own compare example:

fn compare<T: Describable>(a: &T, b: &T) -> bool {
    a.describe() == b.describe()
}

Here, both a and b are typed as &T — the SAME generic parameter T,
constrained to implement Describable — which forces the compiler to
require that whatever concrete type is used for a is ALSO used for b
in any given call. This is precisely why this chapter introduced trait
bounds as the more general, more powerful form: impl Trait sugar
simply cannot express a same-type requirement across multiple
parameters, only a shared generic type parameter can.