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

T! — это implicitly unwrapped optional: хранилище всё равно содержит T?, то есть либо значение, либо nil. Отличие от T? проявляется при использовании: если контекст требует обычный T, Swift пытается извлечь значение автоматически; при nil это приводит к аварийному завершению.

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

Такой механизм появился как компромисс между безопасной моделью Optional и ситуациями, когда значение гарантированно будет установлено позднее. Особенно важным он был при взаимодействии Swift с Objective-C API и объектами, жизненный цикл которых не позволяет инициализировать свойство сразу.

Однако T! не отменяет возможности отсутствия значения. Он лишь переносит проверку с места объявления на момент фактического использования.

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

Обычный T? заставляет явно обработать отсутствие значения: применить optional binding, optional chaining или значение по умолчанию. Это делает потенциальную ошибку заметной в месте использования.

У T! компилятор часто скрывает извлечение. Код выглядит короче, но если значение ещё не установлено или уже недоступно, ошибка проявится во время выполнения, а не на этапе компиляции.

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

При объявлении T! Swift хранит Optional. Поэтому с таким значением допустимы операции, работающие именно с Optional: проверка на nil, optional binding и optional chaining.

Когда выражение с T! используется там, где требуется T, компилятор добавляет неявное извлечение. Если внутри находится some(value), результатом будет value; если внутри nil, приложение завершится с ошибкой из-за неудачного извлечения.

var token: String! = "abc"
let optionalToken: String? = token
let length = token.count

 token = nil
// let failed = token.count // аварийное завершение
let safeLength = token?.count

В примере присваивание в String? сохраняет Optional-контекст и не требует принудительного извлечения. Обращение к count требует String, поэтому происходит неявное извлечение. После присваивания nil optional chaining остаётся безопасным, а прямое обращение к свойству завершилось бы ошибкой.

T! не следует воспринимать как отдельный безопасный тип. Практическое различие с T? — в степени помощи компилятора: T? требует явного решения, а T! позволяет скрыть его и принять риск runtime-ошибки.

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

Экран создаётся до загрузки объекта модели, поэтому разработчик объявляет модель как Model!. Это уменьшает количество проверок, но любой ранний доступ к модели вызывает аварийное завершение; ошибка также может появиться при изменении порядка инициализации.

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

Предпочтительное решение — обычный Model при обязательной зависимости и Model? при реально возможном отсутствии. Model! оправдан только при чётком жизненном цикле и проверяемом инварианте, что к моменту каждого чтения значение уже установлено.

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

Вопрос: является ли T! отдельным runtime-типом, отличным от T??

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

Вопрос: почему optional chaining с T! не вызывает ошибку при nil?

Ответ: optional chaining явно задаёт безопасный способ работы с Optional. Оно проверяет наличие значения и возвращает nil, если значение отсутствует, вместо неявного извлечения с аварийным завершением. При этом результат цепочки обычно сам становится Optional.

Вопрос: может ли значение T! безопасно передаваться в обобщённую функцию?

Ответ: результат зависит от контекста вывода типа. В контексте, где параметр функции выводится как Optional, в обобщённый параметр попадёт T?; в контексте, требующем конкретный T, компилятор может применить неявное извлечение. Поэтому обобщённый код не должен полагаться на визуальное обозначение !: нужно явно определить, принимает ли функция Optional и как обрабатывает nil.