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

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

Это отличается от where у расширения протокола: такое ограничение обычно влияет только на доступность членов расширения и само по себе не меняет требования соответствия.

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

Associated types позволяют протоколу описывать тип, который каждая реализация выбирает самостоятельно. Одного объявления associated type недостаточно, когда протоколу нужны дополнительные гарантии, например хешируемость ключа или сравнимость элемента.

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

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

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

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

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

Ограничение у associated type является частью требований протокола. При проверке соответствия Swift сначала определяет конкретный тип associated type — явно через typealias или выводом из членов реализации, — затем проверяет все его ограничения.

protocol Keyed {
    associatedtype Key where Key: Hashable
    var key: Key { get }
}

struct User: Keyed {
    let key: Int
}

struct Invalid: Keyed {
    let key: [Int] // Ошибка: Array<Int> не соответствует Hashable
}

func hashKey<T: Keyed>(_ value: T) -> Int {
    value.key.hashValue
}

Для User associated type Key выводится как Int, а Int соответствует Hashable, поэтому соответствие корректно. В Invalid Swift выводит Key как [Int], после чего проверка обязательного ограничения завершается ошибкой.

После ограничения T: Keyed generic-код может использовать гарантии Key: Hashable без отдельного where T.Key: Hashable: это уже следует из самого протокола. При этом такое ограничение не означает, что каждый тип автоматически становится Keyed; соответствие всё равно должно быть явно объявлено или выведено в рамках условного соответствия.

Для сравнения, extension Keyed where Key: Hashable не добавляет обязательное требование всем соответствующим типам. Оно лишь делает члены этого расширения доступными там, где компилятор доказал условие. Поэтому существующее соответствие может оставаться корректным даже без доступа к таким дополнительным членам.

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

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

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

Вариант с ограничением у associated type запрещает некорректное соответствие сразу. Минус — протокол становится строже, поэтому типы с нехешируемыми ключами уже нельзя использовать через него. Для кэша это правильный компромисс: инвариант необходим самой абстракции, а не отдельному удобному методу.

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

Создаёт ли where у associated type условное соответствие автоматически?

Нет. Оно только ограничивает допустимые значения associated type у уже объявленного соответствия. Для generic-типа всё равно нужно объявить условное соответствие с условием вроде where T: Hashable; Swift не создаёт такое соответствие автоматически.

Нужно ли повторять ограничение associated type в каждой generic-функции?

Нет, если generic-параметр ограничен самим протоколом. Например, при T: Keyed компилятор уже знает, что T.Key: Hashable, поскольку это часть контракта Keyed. Повторное ограничение может быть нужно только для другого, более сильного требования.

Что произойдёт, если associated type явно указан, но не удовлетворяет where?

Соответствие будет отвергнуто на этапе компиляции. Явный typealias не отменяет ограничений протокола: он лишь задаёт кандидата на associated type, который затем проверяется на соответствие всем требованиям.