Краткий ответ

Для стандартных коллекций Swift, таких как Array, String и Dictionary, присваивание обычно использует copy-on-write. Новая переменная временно разделяет внутреннее хранилище с исходной, а физическая копия создаётся только перед изменением данных, если хранилище уже используется несколькими значениями.

Исторический контекст

Структуры в Swift должны вести себя как значения: после присваивания изменение одной переменной не должно менять другую. Наивная реализация потребовала бы копировать все элементы сразу, что особенно дорого для больших коллекций.

Copy-on-write сохраняет семантику независимых значений, но откладывает дорогостоящую операцию до момента, когда она действительно необходима. Это компромисс между предсказуемостью value semantics и эффективностью использования памяти.

Постановка проблемы

Рассмотрим две переменные, содержащие одну коллекцию. До изменения их можно безопасно обслуживать через одно внутреннее хранилище, поскольку обе видят одинаковые данные.

При изменении одной переменной нельзя допустить, чтобы другая неожиданно получила этот результат. Если разработчик предполагает немедленную глубокую копию или, наоборот, рассчитывает на общее изменяемое хранилище, он может неверно оценить потребление памяти и производительность.

Подробное решение

При присваивании значения коллекции Swift сохраняет два владельца одного буфера. Перед операцией, изменяющей коллекцию, реализация проверяет, используется ли буфер совместно. Если да, создаётся отдельная копия; затем изменение выполняется только над ней.

var first = [1, 2, 3]
var second = first

first.append(4)

print(first)  // [1, 2, 3, 4]
print(second) // [1, 2, 3]

До append коллекции могут разделять хранилище. После append first получает собственный буфер, если прежний буфер был общим. Для second данные остаются прежними.

Важно, что copy-on-write — это деталь реализации, обеспечивающая требуемую семантику значений. Нельзя строить корректность программы на предположении о точном моменте физического копирования или на доступе к внутреннему буферу.

Оптимизация относится к самому хранилищу коллекции, а не автоматически к объектам, лежащим внутри неё. Если массив содержит экземпляры классов, копирование массива не создаёт копии этих экземпляров: элементы-ссылки по-прежнему указывают на те же объекты.

Ситуация из практики

Сервис формирует большой массив моделей для экрана и передаёт его в несколько компонентов. Вариант с безусловным глубоким копированием каждого массива гарантирует независимость, но может заметно увеличить время обработки и расход памяти. Вариант с общей изменяемой ссылкой экономичен, но нарушает изоляцию изменений и усложняет reasoning о состоянии.

Выбран стандартный Array с value semantics и copy-on-write. Компоненты получают независимые значения логически, а копирование большого буфера происходит только у компонента, который действительно меняет коллекцию. Если модели являются классами и их состояние тоже должно быть независимым, дополнительно применяют копирование самих моделей или используют структуры с value semantics.

Результат: неизменяемые сценарии используют общее хранилище, а изменяющиеся получают изолированную копию. При этом разработчики не должны считать copy-on-write заменой синхронизации или глубокому копированию ссылочных элементов.

Что кандидаты часто упускают

Создаётся ли копия сразу после присваивания коллекции?

Обычно нет: значения могут временно разделять внутренний буфер. Копирование откладывается до мутации, когда совместное использование стало несовместимо с value semantics. Однако точная стратегия и момент выделения памяти являются деталью реализации, поэтому нельзя использовать это как публичный контракт для управления ресурсами.
Гарантирует ли копирование массива независимость объектов внутри него?

Нет. Копируется структура коллекции и её хранилище элементов, но экземпляры классов внутри массива остаются общими ссылками. Поэтому изменение свойства такого объекта будет видно через оба массива; для полной независимости требуется явно создать копии объектов или моделировать элементы структурами.
Делает ли copy-on-write доступ к коллекции безопасным при одновременном изменении из разных потоков?

Нет. Copy-on-write решает задачу семантики значений и оптимизации копирования, но не делает произвольный общий доступ к переменной потокобезопасным. При конкурентном чтении и изменении нужно обеспечить синхронизацию, изоляцию состояния или использовать подходящий concurrency-механизм Swift.