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

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

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

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

Условные конформности решают другую задачу: generic-тип получает соответствие протоколу только для допустимых специализаций. Совместное использование этих механизмов позволяет выразить зависимость соответствия от параметров типа без создания отдельных обёрток или ручных проверок во время выполнения.

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

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

Ошибочное предположение может привести к лишним объявлениям конформности. В некоторых случаях это вызовет конфликт повторного соответствия, а в других — неверное ожидание, что базовые требования доступны без выполнения условий условной конформности.

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

Swift рассматривает соответствие дочернему протоколу как соответствие всей иерархии его протоколов-предков. Поэтому при объявлении условной конформности к дочернему протоколу тип получает и соответствие родительскому, но только когда выполнены условия where.

Например:

protocol Storable { }
protocol CodableStore: Storable { }

struct Box<Element> { }

extension Box: CodableStore where Element: Equatable { }

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

save(Box<Int>())

Здесь Box<Int> соответствует CodableStore, потому что Int соответствует Equatable. Через наследование протоколов это же значение соответствует Storable, поэтому его можно передать в save.

Для Box с элементом, который не удовлетворяет Equatable, условная конформность не существует. Следовательно, такой Box не соответствует ни CodableStore, ни унаследованному от него Storable.

Компилятор проверяет требования родительского протокола в составе соответствия дочернему. Если дочерний протокол добавляет собственные требования, они тоже должны быть выполнены; одного соответствия родителю недостаточно для обратного вывода соответствия дочернему.

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

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

В библиотеке есть Box<Element>, который должен участвовать в общем механизме хранения только для сравнимых элементов. Команда может объявить соответствие непосредственно Storable и отдельно реализовать специализированный CodableStore, но это дублирует ограничения и усложняет поддержку.

Другой вариант — объявить только условное соответствие CodableStore, наследующего Storable. Он компактнее и гарантирует, что базовый контракт доступен ровно там, где доступен специализированный. Выбранное решение уменьшает риск рассинхронизации условий и позволяет generic-коду, принимающему Storable, использовать Box без дополнительного объявления.

Если же базовое хранение допустимо для всех элементов, а расширенное — только для Equatable, эти соответствия нужно разделить: безусловно объявить соответствие Storable, а условно — CodableStore. Иначе базовая возможность ошибочно ограничится условием Equatable.

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

1. Может ли соответствие родительскому протоколу быть доступно при более слабых условиях, чем соответствие дочернему?

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

2. Достаточно ли соответствия родительскому протоколу, чтобы получить соответствие дочернему?

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

3. Что произойдёт, если отдельно объявить условные соответствия к дочернему и родительскому протоколам с одинаковыми условиями?

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