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

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

Это статическая проверка передачи данных, а не механизм синхронизации. Sendable не делает изменяемый объект потокобезопасным автоматически.

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

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

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

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

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

Ошибка особенно опасна тем, что обобщённая функция выглядит безопасной для одного типа, но становится небезопасной после подстановки другого. Ограничение Sendable делает этот контракт явным и проверяемым для всех вариантов T.

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

В строгой проверке конкурентности Swift ограничение Sendable на T позволяет использовать значение в контексте, где оно пересекает границу задач:

func handoff<T: Sendable>(_ value: T) async -> T {
    await Task.detached { value }.value
}

struct Message: Sendable {
    let text: String
}

String удовлетворяет требованиям Sendable, поэтому Message тоже может быть передан. Если вызвать handoff с несамопередаваемым типом, Swift должен отклонить такой вызов либо потребовать явного, осознанного решения вроде @unchecked Sendable.

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

Ограничение действует на конкретную специализацию обобщённого кода. Тип может иметь условное соответствие: контейнер считается Sendable только тогда, когда его элемент T тоже Sendable.

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

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

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

Вариант с Any был бы гибким, но ухудшил бы типобезопасность и не дал бы компилятору проверить безопасность передачи. Вариант с @unchecked Sendable убрал бы диагностику, но перенёс бы всю ответственность на разработчика.

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

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

Означает ли Sendable, что тип полностью неизменяем?

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

Достаточно ли ограничения T: Sendable для атомарности операций над T?

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

Почему обобщённый контейнер не всегда автоматически является Sendable?

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