Exercise 3: FastAPI's Type Hint "Double Duty" — Possible Solution
====================================================================

THE SINGLE ANNOTATION IN QUESTION
------------------------------
    @app.get("/users/{item_id}")
    async def read_user(item_id: int):
        return {"item_id": item_id}

Only one piece of information is written here about item_id: the
Python type hint, int.

REAL OUTPUT 1 -- REQUEST VALIDATION & PARSING
------------------------------
Per FastAPI's own documentation, "With that type declaration, FastAPI
gives you automatic request 'parsing'" and, from the identical
declaration, "FastAPI gives you data validation." A request to
/users/3 hands the handler a genuine Python int. A request to
/users/foo never reaches the handler at all -- it's rejected first,
with a real structured JSON error body naming exactly which field
failed and why (int_parsing, on the item_id path parameter).

REAL OUTPUT 2 -- THE AUTO-GENERATED /docs PAGE
------------------------------
The identical int annotation is also what FastAPI reads to build its
own automatically generated, interactive Swagger UI documentation at
/docs. That page shows item_id as a required integer path parameter --
generated directly from the source-code type hint, with no separate
documentation file or comment written anywhere by the developer.

WHY "DOUBLE DUTY" IS THE RIGHT DESCRIPTION
------------------------------
A single line of code -- item_id: int -- produces two genuinely
separate real artifacts: a runtime validation/parsing rule enforced on
every incoming request, AND a piece of public, human-readable API
documentation, generated automatically and guaranteed to stay in sync
with the real code, since both come from reading the exact same
annotation rather than being maintained separately by hand. Chapter 2's
own typed converters only ever produced the first of these two --
validating and casting a segment before the view runs -- with no
documentation-generation capability built on top of that same
declaration at all.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the two real, separate outputs by name (validation/
parsing, and the live /docs page) rather than treating "type hint
does more than one thing" as a vague claim, grounds both in FastAPI's
own quoted documentation from the chapter, and explains concretely why
that's a genuine step beyond Chapter 2's own typed-converter table,
which never generated documentation from its own converter
declarations at all.