Challenge 3: Why Rust's Discriminant Prevents What C's Union Cannot — Possible Solution
====================================================================

A Rust enum that carries data (per rust1-6) stores, alongside whichever
variant's actual data is present, a hidden DISCRIMINANT -- an internal
tag recording exactly which variant the value currently is. Critically,
the ONLY way Rust's language lets code access the data inside an enum
is through a `match` (or equivalent pattern-matching construct), and
the compiler REQUIRES every `match` to handle every possible variant.
This means it is structurally impossible to write code that reads a
variant's data without the compiler having first confirmed, via the
discriminant, that THAT specific variant is genuinely the one present
-- there is no code path that lets you "accidentally" read variant B's
data while the value is actually holding variant A. The check isn't a
runtime safety net; it's baked into the only way the language lets you
extract the data at all.

A C union has none of this. Per the chapter, nothing about a union's
memory layout records which member was last written -- there is no
discriminant, no tag, nothing. The language places zero restrictions on
which member can be read at any time; `v.as_int` and `v.as_float` are
both always syntactically valid, regardless of which one was actually
written last. The programmer alone is responsible for remembering,
with nothing in the type system enforcing or even checking it.

Why this makes the union version genuinely undefined behavior, not
just an inconvenience: because C provides no mechanism to determine at
runtime which member is valid, reading the "wrong" one isn't merely
inelegant or hard to track -- the C standard itself declines to define
what happens in that case at all. This is qualitatively different from
an inconvenience (something merely awkward but well-defined); undefined
behavior means the compiler is permitted to assume the situation never
arises and can generate code on that assumption, which is exactly the
warn-box's own point about optimizations producing effects beyond just
"a wrong number."

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism that makes Rust's version impossible
(the discriminant plus match's exhaustiveness requirement, not just "Rust
checks it somehow") and precisely distinguishes undefined behavior from
a mere inconvenience by tying it back to the compiler's own freedom to
assume the bad case never happens.