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

В mutating-методе перечисления Swift разрешает изменять весь экземпляр self, включая его текущий case. Переключение между вариантами — это не изменение отдельного поля, а замена одного значения перечисления другим.

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

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

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

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

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

У перечисления может не быть хранимых свойств, которые можно было бы изменить напрямую. Тем не менее его метод иногда должен перевести экземпляр из одного варианта в другой, например из состояния «красный» в состояние «зелёный».

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

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

mutating сообщает компилятору, что метод получает право записывать новое значение в self. Для перечисления это позволяет присвоить self другой вариант, в том числе вариант со связанными данными.

enum TrafficLight {
    case red, yellow, green

    mutating func next() {
        switch self {
        case .red: self = .green
        case .green: self = .yellow
        case .yellow: self = .red
        }
    }
}

var light = TrafficLight.red
light.next()

После вызова light содержит .green. Старое значение не модифицируется «внутри» объекта: переменная получает новое значение перечисления.

Метод нельзя вызвать на константе, потому что это потребовало бы записи в неизменяемое значение. Для структуры действует тот же принцип, но у неё обычно меняют свойства; у перечисления естественной операцией часто является полная замена self.

Важно отличать это от класса. Экземпляр класса — ссылочное значение, и mutating для методов классов не используется: изменение состояния выполняется через ссылку, а не через замену самого self.

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

Допустим, нужно реализовать конечный автомат загрузки: idle, loading, loaded и failed. Один вариант — хранить состояние в структуре с несколькими флагами. Это позволяет менять отдельные поля, но создаёт риск получить недопустимую комбинацию, например одновременно loading и failed.

Другой вариант — использовать перечисление и метод, который возвращает новый экземпляр. Такой подход хорошо подчёркивает неизменяемость, но требует явно присваивать результат каждого перехода и может быть неудобен при последовательных изменениях.

Практичнее выбрать перечисление с mutating-методами переходов, если объект состояния локально изменяется последовательно. Варианты остаются взаимоисключающими, переходы централизованы, а компилятор не позволяет менять состояние константы. Для многопоточного или строго функционального кода предпочтительнее возвращать новое значение и не изменять исходное.

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

Можно ли внутри mutating-метода перечисления изменить только связанное значение, не заменяя case?

Да, если связанное значение извлечено в изменяемый контекст и такая операция поддерживается синтаксисом конкретного варианта. Но концептуально результатом всё равно становится новое значение перечисления; нельзя считать связанное значение отдельным независимым хранимым свойством экземпляра.

Что произойдёт с копией перечисления после вызова mutating-метода на оригинале?

Копия значения не изменится. Например, если переменную скопировали до перехода из .red в .green, копия продолжит содержать .red. Это следствие value-семантики перечислений, хотя связанные с ними ссылочные объекты могут оставаться общими.

Почему mutating-метод нельзя вызвать через константное значение, даже если фактический переход не меняет состояние?

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