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

Swift позволяет одновременно ограничить generic-параметр базовым классом и протоколом. Такой параметр обязан быть подтипом указанного класса и иметь соответствие протоколу, поэтому generic-код получает доступ и к членам класса, и к требованиям протокола.

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

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

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

Комбинированные ограничения позволяют выразить это требование декларативно. Благодаря этому проверка выполняется компилятором, а реализации не приходится принимать произвольные значения и проверять их пригодность во время выполнения.

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

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

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

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

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

protocol Cacheable {
    var cacheKey: String { get }
}

class Entity {
    let id: Int
    init(id: Int) { self.id = id }
}

final class User: Entity, Cacheable {
    var cacheKey: String { "user-\(id)" }
}

func store<T>(_ value: T) where T: Entity, T: Cacheable {
    let identifier = value.id
    let key = value.cacheKey
}

В store компилятор разрешает обращаться к id, потому что T ограничен классом Entity, и к cacheKey, потому что T ограничен Cacheable. Вызов с User допустим, а со структурой или классом-наследником Entity, не соответствующим Cacheable, — нет.

Это ограничение отличается от обычного протокольного composition в том, что базовый класс задаёт обязательную иерархию, а протокол — дополнительный контракт поведения. При этом Entity не обязан соответствовать Cacheable: соответствие требуется только у фактического типа, подставленного вместо T.

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

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

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

Можно было бы принять Entity и отдельно проверять поддержку кэширования во время выполнения, но это переносит ошибку из компиляции в работу приложения. Можно также сделать два независимых API, однако это дублирует логику и усложняет поддержку.

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

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

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

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

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

2. Обязан ли базовый класс соответствовать протоколу, чтобы его наследник подошёл generic-функции?

Нет. Достаточно, чтобы конкретный тип-наследник имел соответствие протоколу. В примере Entity может не быть Cacheable, тогда как User объявляет это соответствие и удовлетворяет обоим ограничениям.

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

3. Создаёт ли комбинированное ограничение новый тип, который можно использовать отдельно?

Нет. Оно не объявляет новый именованный тип и не добавляет конформность существующим типам. Это условие применимости конкретной generic-сущности.

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