Exercise 3: Why Optionals Catch Bugs at Compile Time Instead of Runtime — Possible Solution
==================================================================================================

In a language with an unchecked null reference (or no real distinction
between "definitely has a value" and "might have nothing"), any
variable of a reference type can potentially be null at any point,
with nothing in the type system itself forcing code to check before
using it. A function can be written, compiled, and shipped that
accesses a property or calls a method on a value that happens to be
null - and the real failure (a null pointer exception, or an
equivalent crash) only shows up the specific moment that exact code
path actually runs with a genuinely null value, which might not happen
until real production traffic hits it.

Swift's optionals move that entire class of real bug earlier in the
process. A plain String is a genuinely different TYPE from a String?
- the compiler itself tracks, for every single value in the program,
whether it's guaranteed to have a real value or whether it might be
nil. Writing code that tries to use an optional's own value directly,
without first unwrapping it via if let, guard let, or ??, is a real
COMPILE ERROR - the code won't even build, let alone ship.

This means the exact category of bug that would otherwise only surface
at runtime - "I forgot to check whether this was null before using
it" - is instead caught the moment the code is written, during a
normal build, by every single developer working on the project, not
just the one unlucky user whose specific real-world input happened to
trigger the missing check first.

ANSWER: In a language with unchecked null references, code that
forgets to check for null compiles and ships fine, and only fails at
runtime when that exact path executes with a genuinely null value -
potentially in production. Swift optionals make "might be nil" part of
the real type itself (T vs. T?), so using an optional's value without
first unwrapping it is a compile error, not a runtime risk - moving
that entire category of bug from "discovered by a user in production"
to "caught by the compiler before the code even builds."

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the real mechanism (optionals as a distinct type
tracked by the compiler) and explains concretely why it shifts a
specific, common class of bug from a runtime failure to a compile-time
error.