Challenge 2: Two Colliding distance Functions — Possible Solution
====================================================================

#include <iostream>

namespace physics {
    double distance(double speed, double time) {
        return speed * time;
    }
}

namespace geometry {
    double distance(double x1, double y1, double x2, double y2) {
        double dx = x2 - x1;
        double dy = y2 - y1;
        return (dx * dx + dy * dy);  // simplified, skipping sqrt
    }
}

int main() {
    std::cout << physics::distance(10.0, 5.0) << std::endl;
    std::cout << geometry::distance(0.0, 0.0, 3.0, 4.0) << std::endl;
    return 0;
}

Output:

    50
    25

Both calls work unambiguously because each is fully qualified --
physics::distance(...) and geometry::distance(...) are, per the
chapter, genuinely distinct entities from the compiler's own
perspective, despite sharing the plain name "distance."

What would happen with `using namespace physics; using namespace
geometry;` and a call to plain `distance(...)`: since both namespaces
would now have their names brought into the same scope, and both
declare a function literally named distance, the compiler would have
two equally-plausible candidates to choose between for an unqualified
distance(...) call -- producing an "ambiguous call" / "reference to
'distance' is ambiguous" compile error, refusing to guess which one
was meant. This is exactly the collision risk the chapter's own
warn-box describes namespaces existing to prevent, reintroduced the
moment using namespace collapses both sets of names into the same flat
scope.

WHY THIS WORKS AS AN ANSWER
------------------------------
This builds two genuinely independent namespaces with a real name
collision (both called distance, with different signatures/purposes),
shows both resolving correctly when fully qualified, and correctly
predicts the specific ambiguous-call compile error that using namespace
on both would reintroduce -- rather than a vague "it would break."