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

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

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

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

Так Swift усиливает value semantics и безопасную работу с inout: вызываемый код получает контролируемый эксклюзивный доступ к исходному хранилищу, а не произвольную возможность одновременно обращаться к нему из разных мест.

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

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

Например, такая передача конфликтует сама с собой: один аргумент начинает изменяющий доступ к balance, а другой пытается прочитать это же значение:

func add(_ value: inout Int, amount: Int) {
    value += amount
}

var balance = 100
add(&balance, amount: balance)

Компилятор диагностирует пересекающиеся доступы. Неверное решение — считать, что чтение второго аргумента завершится до начала изменения первого: для inout изменяющий доступ уже считается активным в рамках вызова.

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

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

Обычно проблему устраняют созданием промежуточной копии:

func add(_ value: inout Int, amount: Int) {
    value += amount
}

var balance = 100
let increment = balance
add(&balance, amount: increment)

Теперь чтение balance завершено до начала inout-доступа. Для структур промежуточная копия обычно соответствует value semantics; для больших коллекций Copy-on-Write может отложить физическое копирование до фактической модификации.

Эксклюзивность относится не только к простым переменным. Конфликт может возникнуть при обращении к одному свойству через разные пути, к элементу коллекции и всей коллекции одновременно, а также при работе с замыканиями и указателями. Часть конфликтов выявляется статически, а часть — динамически, если точный факт пересечения нельзя доказать на этапе компиляции.

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

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

Функция обновления модели принимает её через inout и одновременно вызывает callback, который должен прочитать ту же модель. Такой дизайн создаёт пересекающийся изменяющий и читающий доступ.

Варианты решения:

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

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

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

1. Вопрос: Обязательно ли правило эксклюзивного доступа означает физическое копирование значения?

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

2. Вопрос: Почему чтение одной части структуры иногда конфликтует с изменением другой части?

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

3. Вопрос: Чем опасно устранение конфликта через ссылочный тип?

Ответ: Ссылочный тип может убрать конкретный конфликт доступа, но не устраняет логическую гонку или неочевидное изменение состояния. Несколько переменных будут указывать на один объект, поэтому callback способен изменить состояние, которое другая операция ещё использует. Такой дизайн допустим, когда совместное состояние является намеренной частью модели, но тогда его жизненный цикл, порядок операций и синхронизация должны быть описаны отдельно.