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

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

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

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

@autoclosure решает эту проблему без явного синтаксиса замыкания у вызывающего кода. Поэтому вызов выглядит как передача обычного выражения, хотя внутри функции оно доступно как замыкание.

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

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

Неверное предположение о @autoclosure тоже опасно: выражение может вообще не выполниться, выполниться позже или выполниться несколько раз, если замыкание вызвать несколько раз.

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

При вызове функции параметр с @autoclosure фактически получает замыкание без аргументов. Тело этого замыкания содержит исходное выражение, а не его уже вычисленный результат.

var evaluations = 0

func nextValue() -> Int {
    evaluations += 1
    return evaluations
}

func ignore(_ value: @autoclosure () -> Int) {
}

ignore(nextValue())
print(evaluations) // 0

В примере nextValue() не вызывается, потому что ignore не обращается к параметру. Если внутри функции вызвать value(), выражение выполнится в этот момент. При двух вызовах value() исходное выражение также может вычислиться дважды; @autoclosure не кэширует результат.

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

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

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

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

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

Выбор @autoclosure уместен, если выражение синхронное, вызывается в том же API-контексте и допускает отложенное вычисление. В результате дорогая подготовка сообщения выполняется только при включённом уровне логирования. Если сообщение нужно сохранить для будущего вызова или передать между потоками, лучше явно использовать обычное @escaping-замыкание и отдельно определить правила времени жизни и синхронизации.

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

Выполнится ли автозамыкание ровно один раз?

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

Можно ли передать в @autoclosure уже созданное замыкание?

Нет, параметр @autoclosure ожидает выражение, результат которого соответствует объявленному типу, а не замыкание этого типа. Если API должен принимать поведение как объект первого класса, которое можно хранить, передавать или вызывать явно, следует объявить обычный параметр-замыкание.

Делает ли @autoclosure параметр безопасным для сохранения после завершения функции?

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