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

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

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

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

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

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

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

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

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

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

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

protocol Renderable {
    func render() -> String
}

func process<T>(_ value: T) -> String {
    "общий"
}

func process<T: Renderable>(_ value: T) -> String {
    "специализированный"
}

struct Card: Renderable {
    func render() -> String { "card" }
}

func relay<T>(_ value: T) -> String {
    process(value)
}

let direct = process(Card())
let throughRelay = relay(Card())

В direct компилятор знает, что Card соответствует Renderable, поэтому выбирает ограниченную перегрузку. В relay параметр T не имеет такого ограничения: внутри функции гарантировано только существование некоторого типа T, поэтому выбирается общий вариант. Факт, что при конкретном вызове relay передан Card, не меняет уже скомпилированный выбор внутри тела relay.

Если добавить ограничение T: Renderable к relay, специализированная перегрузка станет доступной и внутри неё. При равной степени специализации компилятор не обязан угадывать намерение разработчика: вызов может стать неоднозначным и завершиться ошибкой компиляции.

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

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

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

Первый — две generic-перегрузки: общая и ограниченная протоколом. Плюс этого подхода — статический выбор и возможность оптимизированного кода без лишних проверок. Минус — результат зависит от статического типа в месте вызова; после передачи значения в неограниченный generic-код специализированная ветка может не использоваться.

Второй — обязательный метод сериализации в протоколе. Он надёжнее для API, где значение может храниться как any Protocol или передаваться между слоями с потерей конкретного типа. Однако такой вариант требует, чтобы каждая реализация протокола предоставляла соответствующее поведение, а общий fallback нужно проектировать отдельно.

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

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

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

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

Почему добавление ограничения к внешней generic-функции меняет выбранную перегрузку?

Ограничение расширяет знания компилятора внутри тела функции. Для неограниченного T нельзя предполагать соответствие Renderable, даже если некоторые реальные вызовы используют такие типы. После объявления T: Renderable это соответствие становится гарантией контракта функции, поэтому ограниченная перегрузка становится применимой.

Что произойдёт, если две перегрузки имеют разные, но одновременно выполняющиеся протокольные ограничения?

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