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

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

Обычно требование делают async. Если синхронный метод действительно нужен, его реализация должна быть nonisolated и не обращаться к изменяемому изолированному состоянию.

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

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

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

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

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

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

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

Изолированное требование нужно объявлять асинхронным:

protocol UserNameProviding {
    var name: String { get async }
}

actor User: UserNameProviding {
    private var storedName = "Ada"

    var name: String {
        storedName
    }
}

func printName(_ provider: any UserNameProviding) async {
    print(await provider.name)
}

Теперь контракт явно сообщает вызывающему коду, что получение значения может потребовать перехода к изоляции actor. Вызов через existential any UserNameProviding также сохраняет это требование.

Альтернативой может быть nonisolated-реализация. Она подходит только для данных, которые безопасно доступны без изоляции, например для неизменяемого и безопасного для передачи значения:

protocol Describing {
    func description() -> String
}

actor User: Describing {
    nonisolated let kind = "user"

    nonisolated func description() -> String {
        kind
    }
}

nonisolated не означает «синхронизировать доступ автоматически». Это заявление, что метод не использует защищаемое изменяемое состояние actor. Нельзя применять его как способ обойти проверку конкурентности.

Другой вариант — изолировать сам протокол глобальным actor, например @MainActor. Тогда его требования будут выполняться в рамках этой глобальной изоляции, но это уже ограничивает всех conforming-типов выбранным actor и может ухудшить переиспользуемость API.

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

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

Первый вариант — сделать протокол асинхронным. Он сохраняет корректность и допускает актуальные настройки, но требует распространить async и await по цепочке вызовов.

Второй вариант — скопировать настройки при создании объекта и реализовать nonisolated-метод. Это даёт синхронный и быстрый доступ, но значение становится снимком и не отражает последующие изменения.

Третий вариант — пометить протокол @MainActor. Он удобен для UI-объектов, однако связывает контракт с главным actor и не подходит для фонового или серверного кода.

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

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

Может ли nonisolated метод actor вызывать другой изолированный метод того же actor?

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

Достаточно ли сделать требование протокола async, чтобы любой доступ к actor стал безопасным?

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

Почему добавление отдельного синхронного метода-обёртки вне actor не решает проблему автоматически?

Внешняя обёртка всё равно должна получить данные из actor. Если она синхронная, ей нечем корректно выполнить потенциально приостанавливаемый переход: блокировать поток вместо await модель Swift Concurrency не разрешает. Поэтому обёртка должна быть асинхронной, работать с заранее полученным снимком или использовать другой явно синхронизированный источник данных.