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

Existentialное значение any P скрывает конкретный тип, которому соответствует значение. Если метод принимает Self, аргумент должен иметь в точности тот же скрытый конкретный тип, но компилятор не может в общем случае доказать это для двух existentialных значений.

В generic-коде проблема решается параметром типа: ограничение связывает оба значения с одним и тем же T. Поэтому операция с Self обычно моделируется через generic-функцию, а не через прямой вызов на any P.

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

Протоколы решают две разные задачи: описывают общий интерфейс для разных типов и позволяют сохранять связь с конкретным типом реализации. Self нужен именно для второй задачи — например, чтобы операция принимала или возвращала тот же конкретный тип, а не произвольное значение протокола.

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

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

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

Небезопасно считать, что два значения одного existentialного протокола совместимы: одно может содержать Score, а другое — DateInterval. Передача второго значения в метод первого могла бы нарушить требование Self.

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

В требовании с Self компилятор должен установить равенство конкретных типов. Generic-параметр делает это статически: если функция принимает два значения типа T, оба аргумента обязаны иметь один и тот же выведенный тип.

protocol Mergeable {
    func merged(with other: Self) -> Self
}

struct Score: Mergeable {
    let value: Int

    func merged(with other: Score) -> Score {
        Score(value: value + other.value)
    }
}

func merge<T: Mergeable>(_ first: T, _ second: T) -> T {
    first.merged(with: second)
}

let result = merge(Score(value: 2), Score(value: 3))

Вызов через any Mergeable не может в общем случае передать методу другое произвольное any Mergeable: совпадение протокольного интерфейса не доказывает совпадение скрытых типов. Специализация generic-функции, напротив, фиксирует один T и позволяет компилятору безопасно выбрать witness-реализацию требования протокола.

Это не означает, что любой метод протокола с упоминанием Self полностью недоступен через existential. Для некоторых ковариантных результатов Swift может вернуть новое existentialное значение. Ограничение особенно существенно, когда Self используется во входном параметре: здесь требуется проверить совместимость типов до вызова.

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

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

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

Рассматривались варианты:

Оставить generic API — сохраняет статическую проверку типов и не требует приведений, но вызывающий код должен заранее знать конкретный тип и не может свободно смешивать элементы разных реализаций.
Использовать приведение типов во время выполнения — позволяет работать с existentialными значениями, но добавляет ветвление, возможный отказ операции и зависимость от динамической проверки.
Сделать type erasure с операцией, принимающей любое значение — упрощает хранение, но меняет контракт: типовая безопасность переносится из сигнатуры в реализацию обёртки.

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

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

Означает ли наличие Self в протоколе, что протокол нельзя использовать как any Protocol?

Нет. Современный Swift допускает existentialное значение для многих протоколов с Self и associated type. Ограничение касается не самого хранения, а конкретных членов, для вызова которых требуется знать или сопоставить скрытый тип.

Поэтому протокол можно использовать как тип коллекции или параметр API, если вызываемый интерфейс не требует недоступной информации о конкретном Self. Для типобезопасных операций с этим типом обычно нужен generic-контекст.
Почему два значения any P нельзя считать имеющими один тип только потому, что они соответствуют одному протоколу?

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

Generic-параметр T выражает именно это равенство: два параметра типа T должны быть совместимы с одной конкретной специализацией. Если требуется принимать разные типы, их нужно описать отдельными параметрами, но тогда операция с Self уже не будет автоматически допустима.
Можно ли решить проблему, заменив Self на тип протокола в параметре метода?

Иногда это возможно, но смысл контракта изменится. Метод, принимающий any P или более общий протокольный тип, разрешает передавать любую реализацию этого протокола, а не только тот же конкретный тип.

Такая замена подходит, если операция действительно поддерживает смешивание разных реализаций. Если же объединять можно только значения одного типа, отказ от Self ослабит модель и перенесёт проверку совместимости в runtime или в код реализации.