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

Требование протокола должно быть объявлено с mutating, потому что оно разрешает реализации изменять или даже заменять значение self. Для структуры это необходимо: без mutating метод протокола считается доступным и на неизменяемом экземпляре.

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

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

Swift сочетает значимые типы — структуры и перечисления — со ссылочными типами — классами. Протоколы должны одинаково описывать поведение для обоих вариантов, не заставляя структуры становиться классами и не скрывая возможность изменения значения.

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

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

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

Обратная ошибка тоже существенна: если добавить mutating в требование без необходимости, вызов метода потребует изменяемый экземпляр или доступ через inout. Это может усложнить API и ограничить использование значения в неизменяемом контексте.

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

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

protocol Resettable {
    mutating func reset()
}

struct Counter: Resettable {
    var value = 10
    mutating func reset() { value = 0 }
}

final class Session: Resettable {
    var active = true
    func reset() { active = false }
}

func clear<T: Resettable>(_ value: inout T) {
    value.reset()
}

В этом примере Counter обязан пометить реализацию mutating. Session этого не делает: класс изменяет состояние объекта по ссылке, поэтому специальная аннотация для метода класса не требуется.

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

Для generic-кода правило определяется именно статическим ограничением протокола. Если функция принимает T: Resettable, компилятор учитывает возможность мутации и обычно требует передать значение с изменяемым доступом, например через inout. Это часть контракта, а не случайная особенность конкретной структуры.

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

Допустим, протокол описывает сброс состояния кэша. Один вариант — объявить метод без mutating и реализовать кэш как класс. Это удобно для ссылочной модели, но не позволяет структурам менять собственное состояние при соответствии протоколу.

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

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

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

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

Нет. Даже если конкретная реализация фактически ничего не меняет, статический тип метода допускает мутацию, поэтому экземпляр должен быть доступен для записи. Иначе компилятор не сможет гарантировать неизменяемость константы.
Может ли класс реализовать mutating-требование обычным методом?

Да. Класс может соответствовать протоколу с mutating-требованием без ключевого слова mutating в своей реализации. Для класса изменение свойств объекта не означает замену значения self, поэтому модель ссылочной семантики уже предоставляет необходимую возможность.
Что произойдёт, если метод структуры заменяет весь self?

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