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

Литерал nil сам по себе не задаёт конкретный тип: он может представлять отсутствие значения в разных вариантах Optional. Поэтому Swift требует контекст, который определит, например, что это Int? или String?.

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

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

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

Если написать let value = nil, компилятор не знает, какой тип должен быть у value: Int?, String? или другой опциональный тип. Аналогичная неоднозначность возникает при вызове перегруженной функции, если несколько перегрузок принимают опциональные значения разных типов.

Попытка угадать тип привела бы к неустойчивому и потенциально ошибочному коду. Поэтому Swift останавливается на этапе компиляции и требует явно предоставить типовой контекст.

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

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

Например, объявление опциональной переменной задаёт контекст, поэтому присваивание допустимо:

let number: Int? = nil
let text = Optional<String>.none

func accept(_ value: Int?) {}
accept(nil)

В первом случае тип задаёт аннотация Int?, во втором — явное указание Optional<String>, а в третьем тип известен из параметра функции. Без такого контекста вывести тип нельзя.

Важно отличать отсутствие значения от самого опционального типа. nil не является значением Int, String или другого базового типа; это способ создать пустое значение соответствующего Optional<Wrapped>.

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

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

Допустим, у API есть две перегрузки: одна принимает Int?, другая — String?. Вызов с одним nil неоднозначен: обе функции одинаково соответствуют переданному литералу.

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

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

Можно ли вывести тип nil в generic-функции, принимающей произвольный тип?

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

Потому что nil совместим с каждым подходящим опциональным параметром. Если перегрузки отличаются только типом обёрнутого значения, например Int? и String?, у компилятора нет основания предпочесть одну из них. Явное указание типа опционального значения делает выбор однозначным.
Чем отличается nil от значения Optional.none?

По смыслу оба обозначают отсутствие значения, но nil — это литеральная запись, а Optional.none — конкретный вариант перечисления Optional с уже определённым типом. Поэтому Optional<Int>.none имеет однозначный тип, тогда как отдельный nil получает тип только из окружающего контекста.