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

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

Иными словами, ограниченное расширение отвечает на вопрос «когда доступен этот член», а протокол-наследник — «каким требованиям обязан удовлетворять тип».

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

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

Однако доступность члена и наличие соответствия — разные задачи. Для описания нового обязательного контракта Swift использует наследование протоколов, а не условное расширение существующего протокола.

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

Предположим, некоторый член должен работать только для типов, чей associated type поддерживает определённую возможность. Если выразить это только через ограниченное расширение, типы не обязаны выполнять новый контракт, а generic-код не сможет использовать сам факт наличия этого члена как доказанное соответствие.

Если же объявить протокол-наследник, соответствие ему становится отдельным типовым фактом. Это повышает строгость API, но требует от конкретных типов явно принять новый контракт.

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

Ограниченное расширение протокола добавляет член только для тех conforming-типов, которые удовлетворяют условию. Само условие не становится обязательным требованием исходного протокола и не создаёт автоматического соответствия новому протоколу.

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

protocol Store {
    associatedtype Value
}

extension Store where Value: Equatable {
    func hasEqualValue(_ lhs: Value, _ rhs: Value) -> Bool {
        lhs == rhs
    }
}

protocol EquatableStore: Store where Value: Equatable { }

func compare<S: EquatableStore>(_ store: S, _ a: S.Value, _ b: S.Value) -> Bool {
    store.hasEqualValue(a, b)
}

В примере любой Store с Equatable-значением может получить метод hasEqualValue, но это не делает его автоматически EquatableStore. Только явное соответствие EquatableStore позволяет передать тип в compare.

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

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

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

Рассматривались два варианта. Добавить новый метод в исходный протокол нельзя без изменения обязательного контракта всех conforming-типов. Ограниченное расширение не даёт generic-коду отдельной гарантии соответствия. Новый протокол-наследник делает контракт явным, но требует объявлять соответствие там, где библиотеке нужно использовать это ограничение.

Выбранное решение — оставить вспомогательный метод в ограниченном расширении, а для API, которому нужна формальная гарантия, определить протокол-наследник. Это сохраняет совместимость существующих типов и одновременно позволяет строить строгие generic-ограничения.

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

Становится ли тип автоматически соответствующим протоколу-наследнику, если он удовлетворяет условию ограниченного расширения родительского протокола?

Нет. Наличие подходящего associated type делает член расширения доступным, но не создаёт декларативного соответствия другому протоколу. Соответствие должно быть объявлено явно, потому что оно является частью статической модели типов и участвует в выборе generic-ограничений.

Можно ли вызвать член ограниченного расширения через параметр, ограниченный только родительским протоколом?

Только если generic-ограничения дополнительно доказывают условие расширения. Само соответствие родительскому протоколу недостаточно: его associated type может не удовлетворять нужному ограничению. Поэтому generic-функции требуется ограничение на associated type или параметр протоколом-наследником.

Что выбрать для публичного API: ограниченное расширение или протокол-наследник?

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