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

P & Q — это не новый номинальный протокол, а составное ограничение, требующее одновременного соответствия типу P и типу Q. Поэтому тип должен явно соответствовать каждому исходному протоколу, а P & Q можно использовать только для ограничений generic-кода, параметров, возвращаемых значений или existential-значений.

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

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

Однако протоколы в Swift остаются номинальными сущностями: соответствие регистрируется отдельно для каждого объявленного протокола. Составление ограничений не создаёт новую запись о соответствии и не добавляет нового набора требований.

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

Попытка трактовать P & Q как самостоятельный протокол смешивает две разные модели: номинальное соответствие и композицию ограничений. Из-за этого разработчик может ожидать, что достаточно объявить соответствие составному типу или что такой тип можно расширить собственными требованиями.

На практике составная запись не имеет собственного имени, witness table или независимой реализации. Компилятор проверяет её как логическое «соответствует P и одновременно соответствует Q».

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

В generic-коде составное ограничение даёт доступ ко всем требованиям обоих протоколов:

protocol Readable {
    func read() -> String
}

protocol Identifiable {
    var id: Int { get }
}

func describe<T: Readable & Identifiable>(_ value: T) -> String {
    "\(value.id): \(value.read())"
}

Параметр T здесь сохраняет конкретный тип и получает оба набора требований. При этом соответствия всё равно принадлежат Readable и Identifiable по отдельности.

Нельзя объявить новый протокол, эквивалентный Readable & Identifiable, одной только записью композиции. Если комбинация является частью публичного контракта, следует объявить именованный протокол-наследник и разместить в нём нужные требования. Такой протокол становится отдельной номинальной сущностью и может использоваться в декларациях, документации и API.

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

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

В SDK нужно передать в функцию объект, который можно читать и однозначно идентифицировать. Вариант с Readable & Identifiable краток и не создаёт лишнего публичного типа, поэтому он удобен для одной внутренней функции.

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

Оптимальное решение зависит от границы API: для локального generic-ограничения выбирают композицию, для устойчивого публичного контракта — отдельный протокол-наследник. Результатом становится явная модель соответствий без ошибочного ожидания, что композиция сама создаёт новую конформность.

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

Достаточно ли соответствия одному протоколу, чтобы тип удовлетворял P & Q?

Нет. Составное ограничение выполнено только при одновременном соответствии всем указанным протоколам. Если отсутствует соответствие хотя бы одному из них, generic-вызов или присваивание такому типу недопустимы.

Создаёт ли P & Q новый associated type или собственные default implementations?

Нет. У композиции нет собственных членов, associated types и реализаций по умолчанию. Все требования и реализации берутся из P и Q; если между ними есть конфликтующие требования, его нужно разрешать на уровне исходных протоколов и конкретного типа.

Когда композицию стоит заменить протоколом-наследником?

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