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

Условительное приведение к any P & AnyObject успешно только тогда, когда динамическое значение одновременно соответствует протоколу P и является экземпляром класса. При успехе новый объект не создаётся: меняется лишь статическое представление той же ссылки на объект.

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

Протоколы в Swift позволяют описывать поведение независимо от конкретного типа, а AnyObject ограничивает значение классами. Составные протокольные типы появились как способ выразить требование «объект должен соответствовать нескольким интерфейсам одновременно», не создавая отдельный протокол только ради объединения ограничений.

Явная форма any P подчёркивает, что используется existential-тип: значение может содержать любой конкретный тип, соответствующий P.

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

Проверка только соответствия P недостаточна, если дальнейший код рассчитывает на ссылочную семантику: идентичность объекта, слабые ссылки или изменение общего состояния. Значение-структура может реализовать P, но не удовлетворяет ограничению AnyObject.

Ошибочное предположение, что упаковка структуры в Any превращает её в объект класса, приводит к неверной логике приведения и ожиданию общей изменяемой ссылки.

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

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

конкретный тип реализует P;
конкретный тип является классом.

protocol Describable {
    var text: String { get }
}

struct Report: Describable {
    let text = "struct"
}

final class Document: Describable {
    let text = "class"
}

let values: [Any] = [Report(), Document()]
let objects = values.compactMap { $0 as? any Describable & AnyObject }
print(objects.count) // 1

Report соответствует Describable, но не проходит проверку AnyObject. Document удовлетворяет обоим требованиям и попадает в результат. Приведение не копирует Document и не меняет его динамический тип — оно только предоставляет доступ к нему через составной existential-тип.

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

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

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

Можно было бы объявить отдельный протокол, наследующий AnyObject и Notifiable. Это делает ограничение явным на уровне API, но добавляет новый тип только для объединения требований. Приведение к any Notifiable & AnyObject не требует такого вспомогательного протокола и удобно на границе динамических данных, например при обработке [Any].

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

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

Меняет ли такое приведение конкретный тип объекта?

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

Пройдёт ли проверку структура, которая реализует P, если она упакована в Any?

Нет, если целевой тип содержит AnyObject. Упаковка структуры в Any скрывает её конкретный тип, но не превращает значение в экземпляр класса. При приведении Swift извлекает динамический тип и обнаруживает, что требование ссылочной природы не выполнено.

Достаточно ли статического типа any P для гарантии AnyObject?

Нет. Если P не ограничен AnyObject, значение типа any P может содержать как класс, так и структуру. Для гарантии ссылочной семантики ограничение должно быть задано в объявлении протокола или в целевом составном типе, например any P & AnyObject.