Exercise 3: Why One Shared navigationDestination Beats a Destination Per Link — Possible Solution
=========================================================================================================

If a destination view were embedded directly inside every single
NavigationLink instead, a list with many rows - or a real, dynamic
list whose row count changes as data updates - would need that exact
same destination-building code repeated (or at minimum, re-evaluated)
once per row, every single time. For a small, fixed list of five
tasks the real cost of that repetition is negligible, but the same
pattern applied to a list of hundreds of real items, or one whose
contents change dynamically, means real, unnecessary duplicated setup
work scattered across every individual link.

Routing every Task through one shared
.navigationDestination(for: Task.self), attached once at the
NavigationStack's own level, decouples "what data was tapped" (each
individual NavigationLink's own concern) from "what view to show for
that kind of data" (a single, centralized concern, defined exactly
once). This mirrors a genuinely useful separation-of-concerns
principle: each row only needs to know and declare its own specific
value, not carry around a full copy of the destination-building logic
itself.

There's also a real, practical maintenance benefit: if TaskDetailView
itself needs to change later - a different layout, extra data shown,
whatever the real update turns out to be - there's exactly ONE real
navigationDestination modifier to update, rather than needing to find
and change a destination view embedded separately inside every
individual NavigationLink scattered throughout the list.

ANSWER: A single shared navigationDestination avoids repeating
destination-building logic once per row, decouples "what was tapped"
from "what to show for it," and means a future change to the detail
view only needs to happen in one real place - a genuinely more
maintainable design than embedding a destination view inside every
individual link, especially as a list grows larger or its own contents
change dynamically.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the real, concrete costs (repeated setup work, harder
maintenance) that a per-link destination pattern would carry, and
explains how the chapter's own shared-destination design avoids them.