Может ли ARC разместить экземпляр класса в стеке, если он не покидает функцию?
На уровне языка ARC не гарантирует физическое размещение экземпляра класса ни в стеке, ни в куче. Обычно экземпляр класса рассматривается как объект ссылочного типа с управляемым временем жизни, а конкретные оптимизации хранения скрыты от программы.
Компилятор может устранить или преобразовать выделение памяти, если это сохраняет наблюдаемое поведение: идентичность объекта, порядок вызовов deinit и доступность ссылок. Поэтому корректность программы нельзя основывать на предположении, что локальный экземпляр класса обязательно находится в стеке или обязательно освобождается при выходе из функции.
ARC появился как способ автоматизировать ручное управление счётчиком сильных ссылок. Вместо явных операций удержания и освобождения компилятор расставляет необходимые действия сам, сохраняя предсказуемую модель владения без полноценного трассирующего сборщика мусора.
Такой подход разделяет две вещи: семантическое время жизни объекта и физическую организацию памяти. Программа должна рассуждать о сильных, слабых и невладеющих ссылках, но не о том, где именно компилятор разместил данные.
Предположение «локальный объект всегда живёт в стеке» приводит к неверным выводам о производительности и времени вызова deinit. Например, передача ссылки в замыкание, возврат её из функции или сохранение в свойстве может изменить граф владения, хотя исходное создание объекта выглядело локальным.
Обратная ошибка тоже опасна: попытка вручную оптимизировать код, исходя из гарантированной кучевой аллокации каждого класса, может помешать компилятору применить безопасные оптимизации. Наблюдаемыми остаются только предусмотренные языком эффекты — доступность объекта через ссылки, его идентичность и корректный вызов deinit.
ARC управляет владением, а не фиксирует место размещения. Сильная ссылка увеличивает время жизни объекта, слабая не продлевает его, а unowned предполагает, что объект всё ещё существует. Ни один из этих механизмов не даёт прикладному коду API для проверки или принудительного выбора стека либо кучи.
Если объект действительно не покидает функции и его идентичность, deinit и побочные эффекты недоступны наблюдателю в промежуточном состоянии, оптимизатор теоретически может заменить обычную аллокацию более дешёвым представлением или устранить её. Однако наличие ссылочного типа, динамической диспетчеризации, deinit, вызова Objective-C-кода или передачи ссылки в неизвестный код может сделать такую оптимизацию невозможной.
Важно отличать область видимости переменной от времени жизни объекта. Выход из функции лишь удаляет конкретную локальную сильную ссылку; объект может продолжить жить из-за другой сильной ссылки, захвата замыканием, свойства, контейнера или значения Any.
Практическое правило: для управления производительностью измеряют реальные аллокации и время жизни, а для корректности проектируют граф владения. Нельзя использовать адрес объекта, предполагаемое место размещения или момент выхода из функции как замену анализу ссылок.
В обработчике создаётся небольшой вспомогательный класс, который используется только внутри функции. Разработчик ожидает, что он всегда будет стековым, и начинает передавать его адрес в небезопасный API после завершения вызова. Это неверно: оптимизация хранения не продлевает время жизни объекта и не делает указатель безопасным.
Рассматривались два варианта. Можно было полагаться на текущую реализацию компилятора, но это хрупко и ломается при изменении оптимизаций; можно было явно управлять временем жизни через корректное владение и границы безопасного вызова. Выбран второй вариант: объект передаётся только в пределах гарантированного времени жизни, а для небезопасного API используется отдельный контракт владения. В результате поведение не зависит от режима оптимизации и версии компилятора.
deinit при выходе из функции?Нет. При выходе из функции исчезает локальная сильная ссылка, но экземпляр уничтожается только после освобождения последней сильной ссылки. Другими владельцами могут быть свойства, контейнеры, замыкания, задачи или временные значения, созданные вызывающим кодом.
Надёжно — нет. Адрес сам по себе не является контрактом стека или кучи, а преобразование адреса в небезопасный указатель не предоставляет гарантии о времени жизни объекта. Кроме того, перенос или оптимизация представления может сделать такие предположения некорректными.
deinit?Она может удалять лишние операции управления ссылками или объединять их, но не должна нарушать наблюдаемую семантику Swift. Если вызов deinit наблюдаем, компилятор обязан сохранить корректный момент, соответствующий последнему освобождению сильного владения в рамках установленной модели языка. При этом точный машинный порядок внутренних retain/release-операций не является API-контрактом.