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

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

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

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

Эта гибкость полезна, но создаёт важное различие: соответствие одному и тому же конкретному типу нескольким протоколам ещё не означает, что типы, связанные с этими протоколами, совпадают. Swift не делает такое предположение неявно, чтобы generic-код опирался только на формально доказанные ограничения.

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

Предположим, один тип является одновременно источником и приёмником данных. У источника есть Element, а у приёмника — Input. Ограничение T: Source & Sink гарантирует наличие обоих associated types, но не позволяет безопасно передать результат источника приёмнику.

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

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

Составное ограничение Source & Sink проверяет две независимые конформности одного generic-параметра. Associated types Source.Element и Sink.Input остаются независимыми, пока сигнатура не установит связь между ними.

protocol Source {
    associatedtype Element
    func read() -> Element
}

protocol Sink {
    associatedtype Input
    func write(_ value: Input)
}

func transfer<T: Source & Sink>(_ value: T)
where T.Element == T.Input {
    value.write(value.read())
}

Ограничение T.Element == T.Input сообщает компилятору, что результат read() допустимо передать в write. Без него у T.Element и T.Input могут быть разные конкретные типы, даже если T соответствует обоим протоколам.

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

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

В конвейере обработки данных один объект одновременно извлекает элементы и записывает результат. Рассматривались три варианта: использовать только составное ограничение, применить type erasure или потребовать равенство associated types.

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

Если в будущем источник и приёмник должны работать с разными типами, контракт следует изменить: например, добавить преобразователь Element в Input, а не ослаблять типовую безопасность.

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

Может ли Swift вывести равенство associated types из конкретной реализации?

Нет, если равенство не следует из generic-сигнатуры или требований протокола. Даже если все известные сейчас реализации используют одинаковые типы, generic-функция должна быть корректной для любого типа, удовлетворяющего заявленным ограничениям. Поэтому связь нужно выразить явно через where или через дополнительное требование протокола.

Становится ли связь associated types доступной через existential-значение составного протокола?

Не автоматически. Existential скрывает конкретный тип, стоящий за протоколом, а вместе с ним обычно скрываются и конкретные значения associated types. Для алгоритма, которому нужно использовать эту связь, предпочтительнее generic-параметр с явными ограничениями; для хранения разнородных значений может потребоваться type erasure.

Можно ли одному типу соответствовать одному протоколу несколько раз с разными associated types?

Нет. Для пары «конкретный тип — протокол» существует одна конформность, поэтому один тип не может выступать, например, как Source<Int> и одновременно как Source<String>. Если нужны разные типовые роли, их моделируют отдельными обёртками или разными типами, каждая из которых имеет собственную конформность.