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

Значение по умолчанию для associated type используется как fallback: оно применяется, если тип соответствующего члена не задан явно и не выводится из реализации требований протокола. Если компилятор выводит другой тип из реализованных требований, этот выведенный тип имеет приоритет над значением по умолчанию.

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

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

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

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

Рассмотрим протокол кэша: для большинства реализаций ключом будет строка, но отдельные реализации могут использовать целые числа. Если объявить тип по умолчанию неправильно, можно ошибочно считать все реализации одинаковыми или ожидать, что Swift всегда выберет default, игнорируя фактические типы методов.

Неверное понимание особенно опасно в generic-коде: ограничения работают с реально выбранным associated type, а не обязательно со значением, указанным после знака равенства в объявлении протокола.

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

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

Явный typealias в conforming-типе.
Тип, выведенный из реализованных требований протокола.
Значение по умолчанию в объявлении протокола.

Минимальный пример:

protocol Cache {
    associatedtype Key = String
    func value(for key: Key) -> Int?
}

struct StringCache: Cache {
    func value(for key: String) -> Int? { nil }
}

struct IntCache: Cache {
    typealias Key = Int
    func value(for key: Int) -> Int? { nil }
}

У StringCache Key выводится как String из параметра метода. Формально default здесь совпадает с результатом, но источник выбора — совместимая реализация требования. У IntCache associated type явно переопределён как Int, поэтому значение по умолчанию не используется.

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

Для generic-кода важен фактически выбранный тип. Если параметр ограничен Cache, операции с Key должны быть допустимы для любого соответствующего типа; наличие default не означает, что generic-функция может без дополнительного ограничения обращаться с ключом как со String.

Преимущество подхода — меньше явных объявлений и удобный API для типичного случая. Компромисс — менее очевидный контракт: изменение реализации метода может изменить выведенный associated type, а значит, повлиять на соответствие ограниченным generic-функциям.

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

В библиотеке кэширования нужно поддержать строковые ключи по умолчанию и числовые ключи для высокопроизводительного внутреннего кэша.

Вариант с обязательным явным typealias в каждом типе делает контракт очевидным, но добавляет повторяющийся код и повышает порог использования протокола. Вариант с default для Key упрощает типичный случай, однако разработчики могут не заметить, что сигнатура метода автоматически выбрала другой associated type.

Выбран вариант с default String и явным typealias для нестандартных реализаций. Для публичного API это сохраняет удобство основного сценария, а в нетипичных реализациях делает изменение типа ключа заметным при чтении исходного кода. В документации библиотеки дополнительно указывается, что default — это fallback, а не ограничение.

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

1. Может ли conforming-тип заменить default associated type, не объявляя typealias?

Да, если тип можно однозначно вывести из реализации требований протокола. Например, метод, использующий associated type в параметре, может предоставить компилятору достаточно информации для вывода конкретного типа. Явный typealias в таком случае не обязателен.

2. Является ли default associated type ограничением, запрещающим другие типы?

Нет. Запись associatedtype Key = String не означает Key == String для всех реализаций. Она задаёт значение по умолчанию; чтобы зафиксировать тип, нужно использовать соответствующее ограничение, например same-type constraint в generic-контексте или в уточняющем протоколе.

3. Может ли generic-функция, принимающая Cache, всегда передавать строку в метод поиска?

Нет. Generic-функция должна учитывать, что Cache.Key может быть любым типом, разрешённым конкретной конформностью. Значение String по умолчанию не распространяется как универсальное ограничение; для передачи строкового ключа потребуется дополнительное ограничение, связывающее Key со String.