Exercise 2: What private(set) Actually Prevents, and Why It Matters With Multiple Views — Possible Solution
===================================================================================================================

A plain var tasks: [Task] would let ANY code holding a reference to
the TaskListViewModel instance - not just the ViewModel's own methods,
but any View (or any other object) that happens to have access to it -
reassign or directly mutate the tasks array from outside the
ViewModel entirely. A View could, in principle, write
viewModel.tasks.append(someTask) or
viewModel.tasks = [] directly inside its own body or a button action,
completely bypassing the real add(title:priority:) and
toggleDone(for:) methods the ViewModel itself defines.

private(set) var tasks: [Task] genuinely prevents this at the
COMPILER level, not just by convention or code-review discipline -
any code outside TaskListViewModel's own type definition can still
freely READ tasks (iterate it, check its count, display it), but any
attempt to WRITE to it from outside the ViewModel produces a real
compile error. Only the ViewModel's own internal methods, running
inside the type itself, retain the ability to actually mutate the
array.

This matters specifically once more than one View shares the same
ViewModel instance (a genuinely realistic case - a task list and a
separate summary widget might both read from the same
TaskListViewModel). Without private(set), any one of those Views could
directly mutate tasks in a way that skips whatever logic the
ViewModel's own methods are meant to enforce - for instance, skipping
any future validation Course 1's own simple guard !title.isEmpty
check hinted at, or any additional bookkeeping toggleDone(for:) might
someday need to do beyond flipping isDone. Centralizing every real
mutation through the ViewModel's own methods keeps that logic
enforced in exactly one place, no matter how many Views end up reading
from the same shared instance.

ANSWER: private(set) var tasks prevents any code outside
TaskListViewModel itself from directly mutating the array - only the
ViewModel's own methods can, while every other reader can still freely
read it. This matters once multiple Views share the same ViewModel
instance, since it guarantees every real mutation is forced through
the ViewModel's own centralized logic, rather than letting any
individual View bypass it and mutate shared state directly and
inconsistently.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies private(set) as a real, compiler-enforced
restriction (not just a convention) and explains the concrete
multi-View consistency problem it prevents.