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

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

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

Рекурсивное перечисление содержит значение собственного типа напрямую или через другой рекурсивный путь. Без косвенного хранения компилятор не смог бы определить конечный размер такого значения: размер перечисления зависел бы от размера самого себя.

indirect вводит уровень косвенности: associated value хранится отдельно, а перечисление содержит ссылку на это хранилище. Такой механизм позволяет описывать деревья выражений, списки и другие рекурсивные структуры.

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

Без indirect рекурсивное перечисление обычно не компилируется из-за потенциально бесконечного размера. Ошибка при попытке решить проблему созданием класса меняет семантику: экземпляры класса имеют идентичность и разделяемое состояние, тогда как перечисление должно оставаться value type.

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

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

indirect можно применить к отдельному case или ко всему перечислению. В обоих случаях рекурсивное значение хранится через косвенный буфер, поэтому размер самого значения остаётся конечным.

Перечисление в Swift является value type независимо от наличия indirect. При присваивании копируется значение перечисления. Если копия впоследствии изменяется, Swift обеспечивает независимый результат; возможное внутреннее разделение буфера до момента изменения — деталь реализации, аналогичная Copy-on-Write.

indirect enum Expr {
    case number(Int)
    case add(Expr, Expr)
}

var first = Expr.add(.number(1), .number(2))
var second = first
second = .number(10)

// first и second содержат независимые значения перечисления

indirect не делает associated value ссылочным типом в пользовательском смысле и не добавляет оператор идентичности. Однако если associated value самостоятельно содержит экземпляр класса, этот экземпляр по-прежнему может быть разделён между копиями — уже из-за ссылочной семантики класса, а не из-за indirect.

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

Нужно представить арифметическое выражение как дерево и копировать его перед оптимизацией. Вариант с классом позволяет легко строить рекурсивные узлы, но копирование требует явного deep copy; иначе оптимизация одной ветви изменит дерево, используемое другим компонентом.

Вариант с обычным рекурсивным перечислением не компилируется из-за неопределённого размера. Выбранное решение — indirect enum: оно сохраняет удобное сопоставление с образцом и value semantics, а косвенное хранение решает проблему размера. Результат — безопасное логическое копирование дерева; дополнительная цена — косвенное обращение к узлам и возможные аллокации.

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

Обязательно ли indirect превращает перечисление в reference type?

Нет. Он меняет способ физического хранения рекурсивного associated value, но не превращает само перечисление в объект с идентичностью. Копирование перечисления сохраняет value semantics.

Что произойдёт, если indirect-перечисление содержит класс среди associated values?

Ссылочный associated value будет общим после копирования перечисления. Поэтому изменение состояния этого класса может быть видно через обе копии. Это следствие вложенной ссылки, а не особенность indirect.

Почему нельзя считать косвенный буфер доказательством независимого физического копирования?

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