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

Да. Функция с результатом String может использоваться там, где ожидается функция с результатом String?, потому что Swift допускает ковариантное преобразование возвращаемого типа: конкретный результат можно безопасно обернуть в Optional. Обратное преобразование невозможно без проверки, поскольку функция, возвращающая String?, может вернуть nil.

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

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

Совместимость функций с ковариантным возвращаемым типом позволяет безопасно использовать более конкретный поставщик результата в API, которое допускает более общий результат. Это уменьшает необходимость в адаптирующих обёртках.

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

Представим API, принимающее функцию типа «без аргументов, возвращает необязательную строку». Такая функция обязана быть готова вернуть либо строку, либо nil.

Функция, возвращающая только String, удовлетворяет этому контракту: её результат всегда можно представить как String? со значением some. Но функция, возвращающая String?, не удовлетворяет контракту с результатом String, поскольку вызывающий код не умеет обработать отсутствие значения.

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

Правило состоит в том, что тип результата функции преобразуется ковариантно: если String безопасно преобразуется в String?, то и функция, возвращающая String, может быть преобразована в функцию, возвращающую String?. Здесь применяется стандартное необязательное оборачивание, а не принудительное извлечение.

func requiredText() -> String {
    "готово"
}

let provider: () -> String? = requiredText
let result = provider()

print(result as Any) // Optional("готово")

При вызове provider фактическая функция по-прежнему возвращает String, но на границе совместимого типа Swift представляет результат как Optional<String> со значением some("готово").

Обратное направление небезопасно: из результата String? нельзя автоматически получить String. Для этого потребовались бы обработка nil, значение по умолчанию или принудительное извлечение, каждое из которых меняет семантику вызова.

Важно не смешивать это правило с ковариантностью контейнеров в общем случае. То, что конкретное значение можно обернуть в Optional, не означает, что любые обобщённые типы Swift автоматически совместимы при замене параметров типа.

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

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

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

Можно передать функцию напрямую как значение типа () -> String?. Это выбранный вариант: преобразование безопасно, не требует ручного оборачивания и сохраняет контракт API. В результате общий интерфейс допускает отсутствующий текст, а конкретный источник по-прежнему гарантирует наличие строки.

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

1. Работает ли обратное преобразование функции с результатом String? в функцию с результатом String?

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

2. Меняется ли при таком преобразовании фактический результат функции?

Нет, функция не начинает возвращать другой объект или копию строки по смыслу вызова. Меняется вид результата на границе типов: значение String безопасно представляется как Optional<String> в состоянии some. Это преобразование типа результата, а не изменение логики самой функции.

3. Можно ли считать это доказательством, что все обобщённые типы ковариантны в Swift?

Нет. Ковариантное преобразование здесь относится к совместимости функции и её возвращаемого типа, а также к специальному безопасному оборачиванию в Optional. Для произвольных обобщённых типов Swift не следует автоматически ожидать такой же совместимости: её определяют правила конкретного типа и доступные преобразования.