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

Структура не становится безопасной для передачи между задачами только из-за собственного типа-значения. Для автоматического соответствия Sendable Swift проверяет, что каждое её хранимое свойство тоже безопасно передавать; обычная ссылка на изменяемый класс это условие нарушает.

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

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

Подход опирается на проверяемое свойствами правило: значение можно передавать конкурентному коду, если доступ к его внутреннему состоянию не создаёт неконтролируемого совместного изменения.

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

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

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

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

Для структуры или перечисления с автоматически проверяемым соответствием Sendable все хранимые свойства должны удовлетворять требованиям передачи между задачами. Простые типы вроде Int, а также другие корректно проверенные Sendable-типы обычно проходят эту проверку.

Обычный изменяемый класс не считается безопасным автоматически: его экземпляр имеет общую идентичность и может быть доступен через несколько ссылок. Даже свойство, объявленное как let, фиксирует только саму ссылку, но не запрещает изменение объекта, на который она указывает.

struct Snapshot: Sendable {
    let count: Int
}

final class Counter {
    var value = 0
}

struct SharedState: Sendable {
    let counter: Counter // Ошибка проверки Sendable
}

Возможные безопасные варианты различаются по смыслу. Вместо ссылки можно передавать снимок состояния как набор значимых Sendable-полей. Для совместного изменяемого состояния подходит actor, который сериализует доступ к своему изолированному состоянию.

Иногда класс можно сделать Sendable вручную, если он действительно неизменяемый или самостоятельно обеспечивает синхронизацию. Аннотация @unchecked Sendable отключает проверку компилятора и переносит всю ответственность на разработчика; она не добавляет блокировки и не устраняет гонки.

Важно отличать безопасность передачи от изоляции. Sendable не делает операции атомарными и не защищает объект после передачи, а лишь задаёт контракт, при котором значение допустимо пересекать границу конкурентного доступа.

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

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

Первый вариант — добавить @unchecked Sendable. Плюс — минимальные изменения, минус — компилятор больше не обнаружит ошибку, если кэш действительно используется без синхронизации.

Второй вариант — передавать изолированный снимок данных без кэша. Он безопасен и прост, но не позволяет получателю изменять общее состояние. Третий вариант — поместить кэш внутрь actor и обращаться к нему через изолированные методы; это сохраняет совместное состояние и делает порядок доступа явным, хотя добавляет асинхронные границы.

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

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

1. Достаточно ли объявить ссылочное свойство как let, чтобы структура стала Sendable?

Нет. let запрещает заменить ссылку в конкретном экземпляре структуры, но не запрещает изменять состояние самого объекта. Если несколько задач владеют ссылкой на один изменяемый экземпляр, совместное состояние всё ещё существует.

Безопасность может появиться только благодаря неизменяемости самого объекта, actor-изоляции или корректной внутренней синхронизации, а не благодаря let у ссылки.

2. Можно ли считать копирование структуры разделением её состояния между задачами?

Только если все её компоненты имеют подходящую семантику передачи. Значимые свойства действительно копируются независимо, но ссылочные свойства обычно копируют лишь адрес объекта.

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

3. Чем Sendable отличается от защиты состояния actor?

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

Actor предоставляет конкретный механизм изоляции: его состояние доступно через сериализованный исполнитель актора. Значение может быть Sendable без actor-защиты, если оно неизменно или имеет безопасную семантику копирования; и наоборот, ссылка на actor безопасна для передачи именно потому, что доступ к его состоянию изолирован.