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

Классовое ограничение протокола означает, что ему могут соответствовать только классы, а не структуры и перечисления. Благодаря этому generic-код получает гарантию ссылочной семантики: можно использовать идентичность объектов через ===, а existential-значение такого протокола можно хранить в weak-свойстве.

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

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

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

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

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

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

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

Классовый протокол наследует AnyObject. Поэтому соответствующий тип обязан быть классом:

protocol EventSink: AnyObject {
    func receive()
}

final class Controller {
    weak var sink: (any EventSink)?
}

final class Logger: EventSink {
    func receive() {}
}

func isSame<T: EventSink>(_ first: T, _ second: T) -> Bool {
    first === second
}

Ограничение T: EventSink теперь подразумевает, что T является ссылочным типом. Поэтому оператор === корректен: он проверяет, указывают ли два значения на один экземпляр, а не равны ли их данные.

Классовое ограничение также позволяет объявлять existential-значения такого протокола как слабые ссылки. Когда объект, на который ссылается sink, уничтожается, значение автоматически становится nil; это помогает избежать циклов владения в шаблоне делегирования.

Ограничение не означает, что все реализации наследуются от одного базового класса, имеют NSObject или поддерживают конкретные методы этого класса. Оно гарантирует только ссылочную природу типа. Кроме того, оно не добавляет автоматическое сравнение через ==: равенство и идентичность — разные операции.

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

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

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

Выбран классовый протокол EventSink, потому что делегат должен иметь объектную идентичность и не удерживаться контроллером. Это исключает неподходящие реализации на этапе компиляции, разрешает слабое хранение и делает generic-функции, сравнивающие экземпляры через ===, типобезопасными.

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

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

Делает ли классовое ограничение протокола все его свойства ссылочными?

Нет. Оно ограничивает вид соответствующего типа, но не меняет семантику отдельных свойств. Свойство может возвращать структуру, перечисление или значение другого типа. Ссылочной становится только сама реализация протокола как экземпляр класса.
Гарантирует ли классовый протокол уникальность экземпляра?

Нет. Классовая природа позволяет проверять идентичность, но не требует, чтобы существовал единственный экземпляр. Можно создать несколько объектов одного соответствующего класса; === вернёт true только для ссылок на один и тот же объект.
Можно ли заменить классовое ограничение обычным generic-ограничением на AnyObject?

Это частично решает задачу ссылочной семантики, но не заменяет классовое ограничение самого протокола. Ограничение T: AnyObject применимо только в конкретной generic-точке, тогда как protocol P: AnyObject фиксирует требование для всех соответствий, разрешает слабое хранение existential-значения any P и сообщает намерение непосредственно в контракте протокола.