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

Implicitly unwrapped optional, записываемый как T!, остаётся optional-значением, но Swift может автоматически извлечь из него значение типа T. Если в момент такого извлечения внутри находится nil, выполнение завершается аварийно. Обычный T? не извлекается автоматически: отсутствие значения нужно обработать явно.

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

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

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

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

Обычный optional заставляет явно учитывать состояние nil. Это повышает надёжность, но может сделать код многословным, когда значение действительно гарантированно появится позже.

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

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

T! не является отдельным контейнером, отличным от optional. По смыслу это optional типа T, для которого компилятор в некоторых контекстах автоматически вставляет извлечение значения.

Если контекст допускает optional, значение можно использовать без извлечения: например, применить optional chaining или проверить его через if let. Если же требуется обычный T, Swift пытается развернуть optional автоматически. При nil такое извлечение завершается аварийно, аналогично принудительному unwrap.

var session: String! = nil

let length = session?.count   // безопасно: результат имеет тип Int?

func connect(to value: String) {}
connect(to: session)          // runtime trap: требуется String, но внутри nil

Обычный String? в последнем вызове не позволил бы передать значение без явной обработки. Поэтому T! следует выбирать только при наличии устойчивой гарантии жизненного цикла; во всех остальных случаях предпочтительнее T?, значение по умолчанию или явная ошибка инициализации.

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

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

Экран создаётся из storyboard, а ссылка на его элемент интерфейса доступна только после загрузки представления. Возможны три решения.

Обычный optional требует проверок при каждом использовании, зато корректно отражает возможность отсутствия элемента.
Implicitly unwrapped optional делает код короче, но падение произойдёт при обращении до загрузки представления или после изменения storyboard.
Обычное свойство с явной инициализацией лучше выражает обязательную зависимость, но требует изменить способ создания экрана.

Для неизбежной по контракту storyboard-зависимости T! может быть приемлемым, если обращение происходит только после завершения загрузки представления и это покрыто тестами. Для бизнес-логики и внешних данных предпочтителен T? или явная модель состояния: ошибка не должна маскироваться под гарантированную инициализацию.

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

1. Является ли T! неким третьим состоянием между T и T??

Нет. В runtime это optional-значение, способ использования которого дополнительно влияет на компилятор. Оно может быть nil или содержать значение T; отдельного третьего состояния нет.

2. Всегда ли обращение к T!, содержащему nil, немедленно приводит к падению?

Нет. Падение возникает при попытке извлечь значение в контексте, где нужен обычный T. Проверка на nil, optional binding или optional chaining могут обработать такое значение безопасно. Опасен именно неявный unwrap, а не факт существования переменной T!.

3. Чем T! отличается от ручного принудительного извлечения T??

Результат ошибки одинаков по сути: если значение равно nil, приложение аварийно завершится. Различие в месте контроля: при ручном извлечении разработчик явно видит потенциально опасную операцию, а T! скрывает её в местах, где компилятор выводит требуемый неoptional-тип. Поэтому T! ухудшает локальную видимость риска и требует более строгого контракта жизненного цикла.