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

Результат получает тип String?. Строковое значение автоматически оборачивается в Optional, а nil получает тот же Optional-контекст; поэтому обе ветки приводятся к общему типу Optional<String>.

let useGreeting = true
let result = useGreeting ? "Привет" : nil

print(result as Any) // Optional("Привет")

Если условие ложно, результатом будет nil, но его тип всё равно останется String?.

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

Optional нужен для явного представления отсутствующего значения на уровне системы типов. Вместо неявного специального значения вроде null Swift использует обобщённый тип, который может содержать либо значение, либо nil.

Чтобы код оставался удобным, Swift поддерживает optional injection: значение типа String можно автоматически поднять до String?. Это позволяет использовать обычное значение в контексте, где ожидается Optional.

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

В тернарном операторе обе ветки должны иметь совместимый общий тип. Строка сама по себе не может быть одновременно тем же типом, что и nil, поскольку nil не является самостоятельным значением типа String или универсальным типом.

Неверное понимание этого правила приводит к попыткам явно преобразовать nil, использовать принудительное извлечение или ошибочно считать результат обычной строкой. В последнем случае можно получить ошибку компиляции при передаче результата туда, где требуется String.

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

Литерал nil имеет тип Optional<Wrapped>.none, но конкретный тип Wrapped выводится из контекста. В выражении с веткой String этим типом становится String, поэтому nil интерпретируется как String?.none.

Другая ветка автоматически преобразуется из String в String.some(...). Итоговый тип выражения — String?, а не Any, не String и не отдельный тип тернарного оператора.

Это преобразование не извлекает Optional и не проверяет наличие значения. Оно, наоборот, добавляет уровень Optional к обычному значению. Поэтому результат нужно обрабатывать как Optional: через optional binding, optional chaining, map, ?? или другой подходящий механизм.

Если ветки несовместимы и не могут быть приведены к общему типу, выражение не скомпилируется. Также автоматическое поднятие значения не делает String? взаимозаменяемым с String: там, где требуется гарантированная строка, Optional сначала нужно безопасно извлечь.

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

Представим формирование подписи профиля: если пользователь включил приветствие, нужно вернуть строку, иначе — отсутствие подписи. Тернарное выражение компактно выражает это правило и даёт результат String?.

Возможны три подхода. Принудительное извлечение опасно, потому что при nil приложение завершится аварийно. Возврат Any устраняет часть ошибок типов, но ухудшает проверку на этапе компиляции. Явно указать String? или позволить Swift вывести этот тип — безопаснее и сохраняет точный контракт.

Выбранный вариант — Optional с последующей обработкой в месте использования. Например, интерфейс может показать подпись только при наличии значения, не смешивая отсутствие данных с пустой строкой. Это сохраняет различие между «подпись не задана» и «подпись задана, но пустая».

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

Можно ли считать результат String, если в текущем запуске условие выбрало строковую ветку?

Нет. Тип выражения определяется статически, до выполнения условия. Даже если конкретный запуск выбрал строку, результат всё равно имеет тип String?, потому что другая ветка может вернуть nil.
Что произойдёт, если строковую ветку заменить на уже имеющееся значение типа String??

Результат останется String?, если обе ветки имеют этот тип. Swift не создаёт лишний уровень String?? только из-за тернарного оператора: существующий Optional не оборачивается повторно при обычном согласовании веток.
Чем отличается nil в тернарном выражении от пустой строки?

nil означает отсутствие значения и сохраняет тип String?. Пустая строка — это полноценное значение типа String; при необходимости она будет обёрнута в String?, но извлечение даст строку длины ноль. Это различие важно для API, где отсутствие данных и пустое содержимое имеют разный смысл.