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

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

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

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

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

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

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

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

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

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

protocol Resettable {
    mutating func reset()
}

struct Constant: Resettable {
    let value = 42

    func reset() {
        // Состояние не изменяется
    }
}

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

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

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

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

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

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

Практически это позволяет использовать единый generic-код для разных типов. Однако документация протокола должна уточнять, обязан ли вызов менять состояние по смыслу API, иначе формальная возможность мутации может быть ошибочно воспринята как обязательное поведение.

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

1. Вопрос: означает ли mutating обязательное изменение состояния?

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

2. Вопрос: почему класс не должен писать mutating при реализации такого требования?

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

3. Вопрос: можно ли немутирующее требование реализовать mutating-методом?

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