Exercise 3: Why @Model Requires a Class, Tied to Fundamentals' Value/Reference Guidance — Possible Solution ==================================================================================================================== Per Fundamentals Chapter 4, the real, defining difference between a struct and a class is what happens on assignment: a struct is genuinely COPIED, producing an independent value with no further connection to the original, while a class is genuinely SHARED - every reference points at the exact same single underlying instance. That same chapter's own real guidance was to reach for a class specifically when a type needs shared, stable IDENTITY that must remain consistent across multiple places in a program referring to "the same" real thing over time. A persisted SwiftData object is precisely this kind of case. Once a Task (or JournalEntry) has been inserted into a ModelContext and saved to real disk, every part of the app that fetches or references that specific row needs to be able to genuinely mutate the SAME underlying persisted record - editing a task's title in a detail view needs to update the exact same real database row a list view is simultaneously displaying, not an independent, disconnected copy of it. If @Model worked on a struct instead, fetching the "same" row twice would hand back two separate, independent copies (per Chapter 4's own copy semantics) - editing one wouldn't affect the other, and there would be no real, coherent single source of truth for what that database row's current state actually is. This is exactly the same real reasoning Fundamentals Chapter 4 already applied to TaskStore itself, and Course 2's own Chapter 1 applied again to TaskListViewModel - shared, mutable identity that needs to stay consistent across multiple readers is the recurring real signal for reaching for a class instead of a struct, and a persisted database row is a genuine, concrete instance of exactly that same underlying need, extended now to identity that must additionally survive on real disk across app relaunches. ANSWER: @Model requires a class because a persisted database row needs real, stable, SHARED identity - every part of the app referencing that same row must be able to mutate the identical underlying instance, not an independent copy. This is the same value-type/reference-type distinction Fundamentals Chapter 4 established: shared, mutable identity across multiple readers is the recurring signal for choosing a class over a struct, now applied to identity that persists to real disk rather than only living in memory for one app session. WHY THIS WORKS AS AN ANSWER ------------------------------ This directly connects @Model's real class requirement back to Fundamentals Chapter 4's own value-type/reference-type guidance, explaining the underlying shared-identity need rather than treating the requirement as an arbitrary SwiftData rule.