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

Вложенный контейнер получает условное соответствие, если его внутренний тип сам соответствует требуемому протоколу. Это соответствие может быть получено рекурсивно: сначала проверяется соответствие внутреннего контейнера, затем — внешнего.

Например, если Box<Element> соответствует Persistable при условии Element: Persistable, то Box<Box<ID>> соответствует Persistable, когда ID соответствует Persistable.

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

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

Условные conformances позволяют описать зависимость возможностей контейнера от возможностей его содержимого. Благодаря этому свойства типа сохраняются при композиции обобщённых типов.

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

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

Иначе generic-код получил бы право вызывать требования протокола для контейнера, хотя его элемент этих требований не выполняет. Это привело бы к некорректной модели типов или к невозможности реализовать требования протокола для некоторых специализаций.

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

Условное соответствие записывается как соответствие с ограничением на параметр типа: Box<Element> соответствует Persistable только при Element: Persistable.

При проверке Box<Box<ID>>: Persistable Swift подставляет Box<ID> вместо Element. Затем он проверяет условие Box<ID>: Persistable. Для него снова применяется то же правило, и проверяется ID: Persistable.

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

protocol Persistable { }

struct Box<Element> {
    let value: Element
}

extension Box: Persistable where Element: Persistable { }

struct ID: Persistable { }

func save<T: Persistable>(_ value: T) { }

save(Box(value: Box(value: ID())))

Вызов допустим, потому что ID соответствует Persistable, поэтому Box<ID> получает соответствие, а вслед за ним — Box<Box<ID>>.

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

Условные соответствия проверяются на уровне конкретной специализации типа. Поэтому Box<ID> и Box<String> могут иметь разные наборы доступных протокольных возможностей. Это сохраняет типобезопасность, но иногда увеличивает сложность диагностики ошибок generic-кода.

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

В библиотеке есть Box<Element>, который должен участвовать в сериализации только при сериализуемом элементе. Безусловное соответствие заставило бы реализовать сериализацию для любого Element, что невозможно корректно сделать. Ручные соответствия для Box<Int>, Box<String> и других типов дали бы работающее решение, но плохо масштабировались бы.

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

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

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

Достаточно ли совпадения структуры типов для получения условного соответствия?

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

Например, наличие свойства value у типа не делает его автоматически Persistable. Это отличает протокольное соответствие от структурной типизации.

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

Только если это дополнительное условие также доказано. Если Box<Element> соответствует протоколу при Element: Persistable & Codable, то для Box<Box<ID>> необходимо доказать оба требования для ID.

Недостаточно доказать лишь ID: Persistable: соответствие Box<ID> не будет доступно, пока не выполнено и условие ID: Codable.

Что произойдёт, если две условные конформности приводят к одному и тому же протоколу?

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

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