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

Результат is определяется динамическим типом объекта во время выполнения, а не статическим типом переменной. Проверка успешна, если фактический объект совместим с проверяемым типом: совпадает с ним, является его подклассом или реализует соответствующий протокол.

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

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

Оператор is решает именно эту задачу: он сохраняет полиморфизм, но позволяет выполнить ветвление там, где поведение зависит от конкретного динамического типа.

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

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

Обратная ошибка тоже опасна: is проверяет совместимость типов, а не строгое равенство. Поэтому проверка базового класса будет успешной и для экземпляра его подкласса.

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

is выполняет runtime-проверку типа. Для классов результат будет true, если фактический объект имеет проверяемый класс или является экземпляром его наследника; для протоколов — если объект динамически соответствует этому протоколу.

class Animal {}
class Dog: Animal {}

let animal: Animal = Dog()

print(animal is Dog)    // true
print(animal is Animal) // true

В примере статический тип animal — Animal, но динамический тип объекта — Dog. Поэтому проходят обе проверки: Dog — фактический тип, а Animal — его базовый класс.

Оператор is возвращает только Bool: он отвечает на вопрос о совместимости, но не предоставляет объект как значение более конкретного типа. Если после проверки нужно обращаться к API подкласса, обычно применяют условительное приведение as? с последующим связыванием результата.

is не изменяет объект, не создаёт его копию и не меняет статический тип переменной. Для строгой проверки именно конкретного класса, без учёта наследников, is не подходит: нужно отдельно сравнивать фактический тип, например через type(of:), учитывая ограничения такого решения.

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

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

Сравнение имён типов или ручное хранение строк хуже: такие проверки хрупки при переименовании и не дают компилятору контролировать корректность. Безусловное приведение as! ещё рискованнее, поскольку аварийно завершит программу при неожиданном типе.

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

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

Всегда ли is проверяет точное равенство типов?

Нет. Для классов is проверяет совместимость с типом, включая наследование. Экземпляр Dog одновременно удовлетворяет проверкам is Dog и is Animal, если Dog наследуется от Animal.

Чем is отличается от as??

is возвращает только булев результат и подходит, когда нужно решить, выполнять ли ветку. as? также проверяет совместимость, но при успехе возвращает значение, приведённое к целевому типу, а при неудаче — nil.

Следовательно, is используют для самой проверки, а as? — когда после проверки нужно безопасно получить интерфейс конкретного типа. Безопасное приведение предпочтительнее as!, если тип не гарантирован контрактом программы.

Почему проверка может дать true, хотя переменная объявлена базовым типом?

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

Поэтому ссылка типа Animal может указывать на объект Dog, и animal is Dog вернёт true. Объявление базового типа ограничивает доступный интерфейс переменной, но не превращает сам объект в экземпляр базового класса и не стирает его фактический тип.