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

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

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

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

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

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

Рассмотрим протокол Renderable и расширение, ограниченное условием Self == Text. Возникают два разных вопроса: доступен ли специализированный член самому Text и считается ли Text соответствующим Renderable автоматически.

Неверно считать, что ограниченное расширение объявляет соответствие. Если тип не содержит объявления соответствия протоколу, наличие подходящих членов в таком расширении не делает его conforming-типом. Кроме того, generic-код не может использовать специализированный член, пока его ограничение не доказывает, что параметр равен Text.

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

Self в расширении протокола обозначает конкретный тип, для которого рассматривается член. Условие Self == Text сужает область действия расширения: его методы, свойства или статические члены становятся кандидатами только тогда, когда рассматриваемый тип точно равен Text.

Это условие не является объявлением конформности. Соответствие должно быть задано отдельно, а его требования должны быть выполнены конкретным типом. Расширение с Self == Text может использовать уже объявленное соответствие Text: Renderable, но не заменяет его.

В generic-функции с ограничением только T: Renderable компилятор знает лишь о соответствии неизвестного типа T протоколу. Он не может предположить, что T == Text, поэтому специализированный член недоступен. Доступ появляется после добавления соответствующего ограничения равенства.

protocol Renderable {
    func render()
}

struct Text: Renderable {
    func render() {}
}

extension Renderable where Self == Text {
    var debugName: String { "Text" }
}

func inspect<T: Renderable>(_ value: T) {
    // value.debugName недоступно: T не доказан как Text
}

let name = Text().debugName

Здесь Text().debugName допустимо, поскольку статический тип значения известен. При этом Text не получил соответствие только из-за расширения: оно объявлено отдельно через Renderable.

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

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

Допустим, общий протокол описывает визуализируемые объекты, а специальное отладочное представление нужно только типу Text. Можно добавить это свойство в неограниченное расширение протокола, но тогда оно станет частью интерфейса всех соответствующих типов. Это ухудшит абстракцию и может потребовать бессмысленных реализаций.

Второй вариант — добавить свойство непосредственно в Text. Это проще, но связь свойства с протокольной моделью становится менее очевидной, а повторное использование ограничения сложнее.

Выбранное решение — ограниченное расширение where Self == Text. Оно документирует область применимости на уровне типов и позволяет компилятору проверить вызовы статически. Для generic-кода, которому нужна эта возможность, следует явно выразить ограничение T == Text; результатом будет более узкая, но корректная функция.

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

Вопрос: может ли такое расширение добавить обязательное требование протокола?

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

Вопрос: достаточно ли ограничения T: Renderable для доступа к члену с Self == Text?

Нет. Ограничение T: Renderable не доказывает равенство T и Text. Нужен дополнительный факт, например ограничение T == Text в generic-объявлении или отдельная функция, принимающая именно Text. Generic-код получает только те возможности, которые следуют из доказанных ограничений.

Вопрос: станет ли специализированный член доступен через any Renderable, если фактическое значение внутри имеет тип Text?

Обычно нет. Тип any Renderable скрывает конкретный тип за existential-обёрткой, а на уровне статической проверки известно лишь соответствие протоколу. Компилятор не может считать, что скрытый тип равен Text; для такого доступа нужно извлечь конкретный тип в подходящем generic-контексте или работать напрямую со значением Text.