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

Доступ к хранимому неизменяемому let-свойству actor может выполняться без await, потому что после инициализации его значение не меняется, а значит, чтение не конфликтует с изменяемым изолированным состоянием. Это исключение относится именно к неизменяемой привязке, а не ко всему объекту, на который она может ссылаться.

actor Account {
    let number: Int
    var balance: Int = 0

    init(number: Int) {
        self.number = number
    }
}

func inspect(_ account: Account) async {
    let number = account.number
    let balance = await account.balance
}

number читается синхронно, а balance требует межактерного обращения через await.

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

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

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

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

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

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

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

У actor есть изолированное состояние. Изменяемое свойство, например balance, может быть прочитано извне только через изолированный асинхронный доступ: вызов потенциально должен дождаться очереди actor, поэтому используется await.

Хранимое let-свойство после завершения инициализации не изменяется. Конкурирующая задача не может записать в него новое значение, поэтому чтение не нуждается в защите от одновременной записи. Это не означает, что весь actor становится доступен без await.

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

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

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

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

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

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

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

Достаточно ли сделать свойство let, если оно содержит экземпляр изменяемого класса?

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

Требует ли await чтение вычисляемого свойства actor?

Обычно да, если геттер изолирован actor-ом. Вычисляемое свойство может обращаться к изменяемому состоянию, поэтому компилятор не может считать его простым чтением постоянного значения. Отсутствие await возможно только при явно доказанной неактерной изоляции, например для корректно объявленного nonisolated свойства.

Гарантирует ли чтение let-свойства атомарность связанного с ним состояния?

Нет. Гарантируется лишь неизменяемость самого свойства после инициализации. Если нужно согласованно прочитать несколько значений или выполнить чтение с последующим изменением, эти действия должны рассматриваться как операция над actor-изолированным состоянием; наличие одного let не делает составную операцию атомарной.