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

nil не имеет собственного конкретного типа: это литерал, который может обозначать отсутствие значения в любом Optional<Wrapped>. Если обобщённый параметр Wrapped больше не выводится из других аргументов или ожидаемого типа, компилятор не знает, какой именно Optional требуется, и отклоняет вызов.

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

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

Такой подход предотвращает многие ошибки во время компиляции, но требует явного контекста там, где одно лишь nil не определяет Wrapped.

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

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

На практике это проявляется при вызове generic-функций, создании локальной переменной или возврате nil из функции с ещё не определённым типом результата. Ошибка возникает не из-за невозможности представить nil, а из-за отсутствия информации о типе обёрнутого значения.

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

nil реализуется как литерал, который может быть преобразован в Optional<Wrapped>, если контекст задаёт Wrapped. Сам по себе литерал не выбирает конкретный тип обёртки.

func accept<T>(_ value: T?) {
    print(value as Any)
}

// accept(nil) // Ошибка: T невозможно вывести

let number: Int? = nil
accept(number) // T выводится как Int

func fallback<T>(_ value: T?, defaultValue: T) -> T {
    value ?? defaultValue
}

let result = fallback(nil, defaultValue: 0) // T выводится как Int

В первом вызове у компилятора есть только nil, поэтому T неизвестен. Во втором вызове тип переданного аргумента уже равен Int?, а в третьем T выводится из второго аргумента Int.

Контекстом также может быть явная аннотация переменной, тип возвращаемого значения или параметр конкретного типа, например Int?. Ограничение вроде T: BinaryInteger обычно недостаточно: оно сужает множество вариантов, но не выбирает единственный конкретный тип.

Важно отличать отсутствие значения от отсутствия типа. nil семантически означает нет значения, но тип Optional<Int> и тип Optional<String> остаются разными типами системы Swift.

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

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

Можно было использовать три подхода:

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

Выбрали явный тип результата в публичном API и типизированные аргументы во внутренних generic-вызовах. Это сделало контракт функции понятным и исключило зависимость от случайных подсказок компилятора.

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

Вопрос: Почему объявление переменной только с nil не даёт ей тип Optional<Any>?

Ответ: Swift не подставляет Any автоматически в качестве универсального обёрнутого типа. Optional<Any> — конкретный тип, но выбор его вместо Optional<Int> или Optional<String> изменил бы семантику и потенциально стёр бы полезную информацию о типах. Поэтому требуется явно указать Any?, если именно такой тип нужен.
Вопрос: Достаточно ли ограничения обобщённого параметра протоколом, чтобы вывести его тип из nil?

Ответ: Нет. Ограничение, например соответствие протоколу, задаёт множество допустимых типов, но не выбирает один конкретный тип. Если ни аргументы, ни ожидаемый результат не дают дополнительной информации, параметр остаётся неоднозначным.
Вопрос: Имеет ли .none конкретный тип в отличие от nil?

Ответ: Нет, запись .none также является case обобщённого типа Optional и требует контекста. Она станет конкретной только рядом с известным типом, например Optional<Int>.none или переменной типа Int?. Явно квалифицированная запись задаёт тип, а не сам case .none.