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

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

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

До ARC разработчик вручную управлял балансом удержаний и освобождений объектов. Это давало контроль, но приводило к утечкам, преждевременному освобождению и ошибкам при передаче объектов между функциями.

ARC перенёс управление подсчётом ссылок в компилятор. Компилятор добавляет необходимые операции владения и может оптимизировать их, поэтому исходный текст не следует трактовать как точную последовательность retain и release.

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

Ошибка возникает, когда разработчик считает, что результат функции гарантированно живёт до конца текущей области видимости. Такое ожидание может удерживать объекты дольше необходимого или приводить к неверным выводам о моменте вызова deinit.

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

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

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

Однако сам временный результат не обязан жить до конца лексической области. ARC анализирует семантически значимые использования и может освободить временный объект после последнего из них. Точный момент удаления не является частью контракта программы, если он не следует из наблюдаемого поведения.

final class Resource {
    deinit { print("released") }
}

func makeResource() -> Resource {
    Resource()
}

func use(_ resource: Resource) {
    print("used")
}

func run() {
    use(makeResource())
    print("after use")
}

В run результат makeResource() используется для вызова use. После завершения этого использования временная сильная ссылка может быть освобождена; поэтому полагаться на то, что released обязательно напечатается после after use, нельзя. Если объект должен жить дольше, его нужно явно удерживать сильной ссылкой, например свойством или локальной переменной, чьё дальнейшее использование действительно необходимо.

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

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

Фабрика возвращает объект с сетевым ресурсом, а вызывающий код передаёт его в функцию регистрации. Разработчик ожидает, что объект останется жив до конца метода контроллера, и размещает в deinit обязательное закрытие ресурса. Если после регистрации объект больше нигде не удерживается, его уничтожение может произойти сразу после регистрации.

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

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

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

Передача результата в функцию продлевает его жизнь до конца вызова?

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

Гарантирует ли объявление результата через let его жизнь до конца области видимости?

Нет. let запрещает переназначение, но не превращает область видимости в гарантию времени жизни объекта. ARC может завершить жизнь объекта после последнего семантически значимого использования, если дальнейшее существование переменной не влияет на наблюдаемое поведение.

Можно ли использовать точный момент deinit как часть протокола между функциями?

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