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

Компилятор Swift отклонит такой код: defer не может содержать return, break или continue. Блок defer предназначен только для завершающих действий при выходе из области видимости и не должен изменять направление управления.

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

Механизм defer решает практическую проблему гарантированного освобождения ресурсов: закрытия файла, разблокировки, восстановления состояния или удаления временных данных. Очистка должна выполняться независимо от того, завершилась функция обычным возвратом или ошибкой.

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

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

Если разрешить return внутри defer, разработчик мог бы попытаться подменить исходный результат функции прямо во время очистки. Аналогично break или continue могли бы изменить работу внешнего цикла в момент, когда уже выполняется завершающая логика.

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

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

defer регистрирует действие, которое Swift выполнит при выходе из текущей области видимости. Сам выход может быть вызван return, ошибкой или завершением блока, но переход выполняется вне тела defer; изнутри этого блока нельзя инициировать новый return, break или continue.

Минимальный пример:

func process() -> Int {
    defer {
        print("cleanup")
        // return 0 // Ошибка компиляции
    }
    return 42
}

Правильный вариант — завершить очистку внутри defer, а решение о результате принять в основном теле функции:

func process(_ valid: Bool) -> Int {
    defer { print("cleanup") }
    if !valid {
        return 0
    }
    return 42
}

Таким образом, defer может выполниться перед возвратом, но не может сам стать источником этого возврата. Это разделяет ответственность: основной код управляет результатом и ветвлением, а defer отвечает за финализацию.

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

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

Метод временно блокирует общий ресурс и должен вернуть ошибку при невалидном состоянии. Разработчик помещает в defer разблокировку и пытается сделать там return, если разблокировка обнаружила проблему.

Возможны три подхода. Возврат из defer невозможен на уровне языка. Игнорировать проблему очистки опасно: ресурс может остаться в некорректном состоянии. Перенести проверку и выбор результата в основное тело можно, но тогда нужно гарантировать, что defer всё равно выполнит разблокировку.

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

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

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

1. Выполнится ли defer, если функция завершает работу через return?

Да. При выходе из области видимости Swift сначала выполняет зарегистрированные действия defer, а затем завершает выход. Запрет return внутри defer не означает, что defer не участвует в обработке обычного возврата.

2. Можно ли использовать break или continue внутри defer, расположенного в цикле?

Нет. Эти операторы также запрещены внутри defer, потому что меняют управление внешним циклом. Если нужно условно завершить итерацию или перейти к следующей, решение принимают в теле цикла, а defer оставляют только для очистки.

3. Где должен находиться досрочный выход, если он зависит от результата очистки?

Досрочный выход должен находиться в основном теле функции после явного выполнения операции, от которой зависит решение. Нельзя использовать defer как обработчик, который сначала скрыто меняет управление, а затем определяет результат; это нарушает назначение механизма и делает порядок действий трудно проверяемым.