Challenge 3: Sub for Point, and When Output Differs From Self — Possible Solution
====================================================================

use std::ops::Sub;

impl Sub for Point {
    type Output = Point;
    fn sub(self, other: Point) -> Point {
        Point { x: self.x - other.x, y: self.y - other.y }
    }
}

fn main() {
    let p1 = Point { x: 5, y: 7 };
    let p2 = Point { x: 2, y: 3 };
    let p3 = p1 - p2; // Point { x: 3, y: 4 }
}

WHY THIS WORKS AS AN ANSWER
------------------------------
This mirrors this chapter's Add implementation exactly, swapping the
trait (Sub instead of Add), the method name (sub instead of add), and
the operator inside the body (- instead of +) — the same Output = Point
associated type is appropriate here too, since subtracting one Point
from another still produces a Point.

WHY Output ISN'T ALWAYS THE SAME AS Self — A HYPOTHETICAL EXAMPLE:
imagine a Meters(f64) newtype representing a distance, and implementing
Mul<f64> for Meters to support scaling a distance by a plain number
(meters * 2.0). Here, Self is Meters, and the OTHER operand (f64) is a
genuinely different type from Self — but more importantly, consider
instead implementing Mul<Meters> for Meters to multiply two distances
together: physically, multiplying a distance by a distance produces an
AREA, not another distance — so a well-designed API would define
type Output = SquareMeters (a distinct type from Meters, representing
area) rather than incorrectly returning another Meters. This
demonstrates concretely why Output is its own independent associated
type rather than always defaulting to Self: the RESULT of an operation
can genuinely be a different type from the operands themselves, and
Add/Sub/Mul's associated Output type exists specifically to let each
implementation state that honestly, rather than forcing every
operator's result to always match its input type.