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

Восходящее приведение через as безопасно, потому что отношение «подкласс — базовый класс» проверяется компилятором по объявлению типов. Объект не преобразуется в новый экземпляр и не проверяется динамически: меняется только статический тип, через который к нему обращаются.

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

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

В Swift такой подход согласуется с системой типов: если тип Photo объявлен наследником Media, любой Photo уже является Media. Поэтому компилятор может доказать корректность операции заранее.

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

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

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

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

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

class Media {
    func play() { print("media") }
}

final class Song: Media {
    func lyrics() { print("text") }
}

let song = Song()
let media = song as Media
media.play()

Здесь компилятор знает, что Song наследуется от Media, поэтому as не выполняет условительную проверку и не возвращает Optional. Переменная media статически имеет тип Media, хотя объект в памяти по-прежнему является Song.

В большинстве контекстов Swift способен выполнить такое преобразование неявно, например при передаче подкласса в параметр базового типа. Явная запись as полезна, когда нужно документировать границу абстракции или сделать изменение статического типа очевидным.

Ограничение заключается в потере доступности API подкласса. Чтобы снова обратиться к возможностям Song, потребуется нисходящее приведение, например условительное as?, которое уже может вернуть nil.

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

Медиаплеер принимает Media, потому что умеет запускать любой поддерживаемый медиаресурс. Конкретный вызывающий код создаёт Song, но передаёт его как Media.

Можно сохранить тип Song до самого плеера, однако тогда API пришлось бы делать обобщённым или перегружать для разных подтипов. Это увеличивает связанность и не нужно, если плееру не требуется доступ к тексту песни.

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

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

Может ли корректное восходящее приведение через as вернуть nil?

Нет. Обычное восходящее приведение между совместимыми классами не возвращает Optional, потому что компилятор уже доказал его допустимость. nil может появиться только из-за отдельной операции с Optional, например если исходная ссылка сама имеет optional-тип; это не является результатом неудачи восходящего приведения.
Почему после приведения нельзя вызвать метод, объявленный только в подклассе?

Доступность членов определяется статическим типом переменной. После приведения к базовому классу компилятор обязан считать значение любым экземпляром этого базового класса, включая экземпляры других подклассов. Поэтому API, существующий только у Song, через переменную типа Media недоступен, даже если фактический объект действительно является Song.
Меняет ли восходящее приведение выбор переопределённого метода?

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