Challenge 3: Why operator<< Can't Be a Member Function — Possible Solution
====================================================================

A member function's implicit left operand is always `this` -- the
object the method is called ON. Writing `operator<<` as a member of
Vector2D would mean the LEFT-HAND side of the `<<` expression is
required to be a Vector2D itself (something like `vector << os`), since
member-function call syntax always makes the object it's called on the
left operand.

But per the chapter's own example, the actual usage this chapter is
building toward is `std::cout << myVector` -- the LEFT-hand operand of
`<<` here is `std::cout` (an `ostream&`), and the RIGHT-hand operand is
the Vector2D. If `operator<<` were a member of Vector2D, the compiler
would need `myVector << std::cout` instead, with the object and the
stream swapped -- backwards from how every other `cout <<` statement
in this course, since Chapter 1, has always been written.

Since the desired left operand (`std::ostream&`) is NOT the class being
extended (Vector2D), the operator has to be written as a FREE function
instead -- one that takes BOTH operands explicitly as ordinary
parameters (`ostream& os, const Vector2D& v`), with neither one
supplied implicitly via `this`. This is precisely why the chapter
introduces `friend` alongside it: since the free function isn't a
member, it has no automatic access to Vector2D's private members the
way a genuine member function would, so `friend` is needed to grant it
that access explicitly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the constraint back to member functions ALWAYS making
`this` the implicit left operand, shows precisely why that would force
the operand order backwards for `cout << myVector`, and connects the
free-function requirement to why `friend` becomes necessary as a
direct consequence -- rather than stating the rule as an arbitrary
fact.