Exercise 3: Why SwiftUI Builds Views as Structs, Not Classes — Possible Solution
========================================================================================

SwiftUI's own core mechanism, previewed in earlier chapters, is that a
view's body describes what the UI should look like for the CURRENT
state - and every time relevant state changes, SwiftUI recreates the
affected view values fresh, comparing the new description against the
previous one to figure out what actually needs to change on screen.
This means view values are created and thrown away constantly, far
more often than a typical class instance would be in most other
programs.

Connecting this to the copy-vs-share distinction: because a struct is
a value type, creating a fresh Rectangle-style view value is just a
plain, lightweight copy of its own properties - a genuinely cheap
operation with no shared identity or reference bookkeeping involved at
all. If View were a class instead, every one of those constant
recreations would mean allocating a brand-new object on the heap.

Connecting this to ARC specifically: every class instance is tracked
by Automatic Reference Counting - each allocation and deallocation
involves real, ongoing reference-count bookkeeping. Doing that
bookkeeping for every single view value, recreated potentially dozens
of times per second as a UI updates, would add real, unnecessary
overhead that a plain struct copy - with no ARC involvement at all -
simply doesn't incur.

So the choice isn't arbitrary: structs give SwiftUI both a cheap way to
create and discard view values constantly (value-type copying, not
class allocation) and freedom from ARC's own per-instance reference-
counting overhead - both properties a UI framework that recreates its
own view descriptions this often genuinely needs.

ANSWER: SwiftUI views are structs because SwiftUI recreates view
values constantly as state changes, and a struct's value-type copying
is a cheap operation with no shared identity to track - unlike a class,
which would require heap allocation and ongoing ARC reference-count
bookkeeping for every single recreation. Structs let SwiftUI create and
discard view values this frequently without the overhead classes and
ARC would otherwise add.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects SwiftUI's own constant view-recreation behavior to both
concepts named in the question - cheap value-type copying versus
class allocation, and the absence of ARC overhead for structs -
explaining the design choice rather than merely restating it.