В каком случае замыкание может быть сбегающим, но не помечено ключевым словом @escaping?

Замыкания @escaping: когда компилятор Swift делает исключения

Замыкание в Swift по умолчанию считается non-escaping — компилятор предполагает, что оно будет выполнено в пределах текущей области видимости функции и не сохранится для последующего использования. Однако существуют специфические случаи, когда замыкание фактически является сбегающим, но не требует явной аннотации @escaping.

Основные сценарии исключений

1. Асинхронные операции с немедленным завершением

Когда функция принимает замыкание и вызывает его синхронно до своего возврата, даже если это происходит через асинхронный API, компилятор не требует @escaping. Классический пример — DispatchQueue.main.async внутри функции:

func executeOnMainThread(_ closure: () -> Void) {
    if Thread.isMainThread {
        closure() // Выполняется немедленно
    } else {
        DispatchQueue.main.async {
            closure() // Выполняется асинхронно, но очередь гарантирует выполнение
        }
    }
}

Хотя замыкание передаётся в async метод, компилятор анализирует, что DispatchQueue.main.async немедленно ставит задачу в очередь и не хранит замыкание неопределённо долго. Система гарантирует выполнение до завершения работы приложения, поэтому формально замыкание «убегает», но Swift делает исключение.

2. Замыкания как аргументы конструкторов

При передаче замыкания в инициализатор структуры или класса, где оно сохраняется в свойстве, обычно требуется @escaping. Однако если свойство помечено как @noescape (устаревшее) или компилятор может доказать, что время жизни объекта ограничено текущим контекстом, аннотация может не потребоваться. На практике это редкий случай в современном Swift.

3. Оптимизации компилятора

Swift компилятор проводит статический анализ потока управления (control flow analysis). Если он может доказать, что:

• Замыкание выполняется на всех путях выполнения функции
• Не сохраняется в глобальном хранилище
• Не передаётся наружу через return

То даже при использовании в асинхронном контексте @escaping может не потребоваться. Однако это больше относится к внутренним оптимизациям, а не к явным правилам языка.

Важное разграничение: почему обычно требуется @escaping

Для контраста рассмотрим случай, где @escaping обязательно:

class TaskManager {
    var completionHandler: (() -> Void)?
    
    func scheduleTask(completion: @escaping () -> Void) {
        // Замыкание сохраняется для использования после return функции
        self.completionHandler = completion
        DispatchQueue.global().async {
            self.work()
            DispatchQueue.main.async {
                self.completionHandler?() // Выполняется значительно позже
            }
        }
    }
}

Здесь замыкание:

1. Сохраняется в свойстве класса
2. Может быть вызвано после уничтожения контекста, в котором была вызвана scheduleTask
3. Требует явного @escaping

Практические выводы

1. Главное правило: если замыкание может быть выполнено после возврата из функции, используйте @escaping.
2. Исключения: определённые системные API (особенно связанные с очередями выполнения) могут не требовать @escaping благодаря гарантиям немедленной постановки в очередь.
3. Безопасность прежде всего: когда есть сомнения, лучше пометить замыкание как @escaping. Это предотвратит потенциальные ошибки времени выполнения и сделает намерения кода явными.

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