Ответ.

История вопроса:

@autoclosure — специальный модификатор Swift, позволяющий автоматически создавать closure из выражения, переданного как аргумент функции. Впервые появился для упрощения синтаксиса и повышения читаемости при написании assert/guard-выражений и отложенного вычисления значений.

Проблема:

Стандартные closures требуют явного синтаксиса ({ ... }). Часто это избыточно, когда логика простая (например, при ленивых проверках). Но если использовать autoclosure, возможно незаметно для разработчика изменить момент выполнения кода или потерять значение side-effect выражения. Также autoclosure не принимает параметров.

Решение:

@autoclosure позволяет писать лаконично:

Пример кода:

func logIfTrue(_ predicate: @autoclosure () -> Bool) {
    if predicate() {
        print("Condition met")
    }
}

// Без autoclosure:
logIfTrue({ 2 > 1 })
// С autoclosure:
logIfTrue(2 > 1)

Ключевые особенности:

@autoclosure позволяет отложить вычисление выражения до момента вызова в функции
@autoclosure может сочетаться с @escaping для асинхронных сценариев
Повышает читаемость интерфейсов, скрывая синтаксис closures от пользователя API

Вопросы с подвохом.

Может ли autoclosure принимать параметры?

Нет. Autoclosure всегда бесконтекстный: принимает 0 параметров и просто "оборачивает" выражение.

В чем разница между типами () -> T и @autoclosure () -> T?

Обычный closure требует явного синтаксиса — autoclosure позволяет передавать выражение, не окружая его фигурными скобками, что существенно влияет на интерфейс функций.

Что произойдет, если autoclosure имеет side-effect?

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

var x = 5
func change(_ value: @autoclosure () -> Int) {
    print(value())
}
change(x += 1) // x увеличится ТОЛЬКО здесь

Типовые ошибки и анти-паттерны

Непонимание того, что выражение не выполняется сразу (lazy behavior)
Использование autoclosure с side-effect выражениями, где ожидается немедленное выполнение
Передача autoclosure в escaping контекст без явного указания @escaping

Пример из жизни

Негативный кейс

При реализации аналитики ошибки писались через функцию, использующую autoclosure для сообщения. Но message-выражение имело side-effect (отправляло сетевой запрос), поэтому реальное выполнение происходило не в том порядке, который ожидал разработчик. Из-за этого статистика собиралась некорректно.

Плюсы:

Синтаксис короткий и выразительный

Минусы:

Неочевидный момент выполнения side-effect’ов
Трудности при отладке

Позитивный кейс

Использование autoclosure в assert-методах, где требуется или вычислять выражение только при необходимости, либо облегчить синтаксис для конечного пользователя API. Код становится короче, side-effect отсутствует.