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

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

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

Value semantics удобны тем, что присваивание и передача значения не создают скрытой зависимости между переменными. Однако полное копирование больших коллекций при каждом присваивании дорого по времени и памяти.

Поэтому Swift использует подход Copy-on-Write: несколько значений могут временно разделять неизменяемое хранилище, а копирование откладывается до первой мутации. Такой механизм лежит в основе эффективной реализации стандартных коллекций и может применяться в пользовательских типах.

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

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

Если же копировать буфер при каждом присваивании, value semantics сохраняется, но теряется главное преимущество Copy-on-Write: операции чтения и простые присваивания становятся unnecessarily дорогими. Ошибка особенно заметна на больших коллекциях.

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

Структура должна владеть ссылочным буфером, а сам буфер лучше объявить final, чтобы однозначно проверять его уникальность. В mutating-операции сначала вызывается isKnownUniquelyReferenced. При единственном владельце копия не нужна; при совместном владении создаётся новый буфер, после чего изменение выполняется уже в нём.

final class Buffer {
    var values: [Int]
    init(_ values: [Int]) { self.values = values }
}

struct CowVector {
    private var buffer: Buffer
    init(_ values: [Int]) { buffer = Buffer(values) }

    mutating func append(_ value: Int) {
        if !isKnownUniquelyReferenced(&buffer) {
            buffer = Buffer(buffer.values)
        }
        buffer.values.append(value)
    }
}

Проверка уникальности относится к ссылочному объекту, а не к самой структуре. Структура остаётся типом со значимой семантикой, хотя внутри использует ссылочное хранилище.

Такой код требует дисциплины: все операции, способные изменить состояние, должны выполнять проверку перед мутацией. Если буфер доступен извне или его можно изменить в обход структуры, независимость значений больше не гарантируется. Нельзя также считать одну проверку достаточной для произвольной многопоточной синхронизации: Copy-on-Write не заменяет защиту от конкурентного доступа.

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

Команда реализует большой тип ImageData, который должен копироваться как значение, но хранит мегабайты пикселей. Прямое хранение массива внутри структуры даёт корректную семантику, однако наивное копирование при каждом присваивании увеличивает затраты. Хранение массива в общем классе без Copy-on-Write экономит память, но приводит к неожиданным изменениям через другую копию.

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

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

1. Достаточно ли сделать ссылочный буфер private, чтобы гарантировать value semantics?

Нет. private ограничивает прямой доступ, но сам по себе не предотвращает ошибку в методах типа. Каждая операция, меняющая буфер, должна проверять его уникальность; иначе одна операция может случайно изменить состояние другой копии.

2. Копируется ли буфер сразу при присваивании структуры?

Обычно нет. При присваивании копируется ссылка на буфер, а не весь массив данных. Физическая копия появляется только перед изменением, если проверка показывает, что буфер разделяется.

3. Почему нельзя заменить проверку уникальности безусловным копированием только в некоторых публичных методах?

Потому что любая другая мутация, забытая без проверки, нарушит семантику типа. Реализация должна централизовать изменение или строго контролировать все пути доступа к буферу; иначе поведение будет зависеть от конкретной операции и станет трудно предсказуемым.