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

Такой массив получает тип [Int?] — массив Optional-значений, где целое число автоматически оборачивается в .some, а nil представляет .none. Если внешний контекст задаёт другой целочисленный тип, например Int32, элементами будут Int32?, но без контекста целочисленный литерал обычно выводится как Int.

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

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

Вывод типов позволяет не записывать этот тип вручную в каждом выражении. При этом Swift сохраняет безопасность: отсутствие значения становится частью типа массива, а не скрытым специальным состоянием произвольного элемента.

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

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

Ошибочное предположение состоит в том, что массив станет [Any] или [Int]. Он не становится [Int], потому что nil невозможно представить как обычный Int, и не обязан становиться [Any], поскольку Swift ищет более точный общий тип.

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

Компилятор выбирает Int для литерала 1 при отсутствии дополнительного контекста. Затем подбирается общий тип элементов, допускающий и Int, и nil. Этим типом становится Optional<Int>.

Концептуально элементы имеют такие значения:

1 преобразуется в Optional.some(1);
nil становится Optional<Int>.none.

Минимальный пример:

let values = [1, nil]

print(values[0] as Any) // Optional(1)
print(values[1] as Any) // nil

Сам массив имеет тип [Int?], а не [Int]. Поэтому извлечение элемента даёт Int?, и перед использованием целого числа требуется optional binding, nil-слияние или другой безопасный способ обработки отсутствия значения.

Если тип нужно зафиксировать явно, это можно сделать аннотацией, например [Int?]. Для массива только с nil такой вывод невозможен без контекста: выражение не содержит информации, какой тип скрывается внутри Optional.

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

Функция загружает значения из источника, где часть записей отсутствует. Вариант с [Any] формально допускает разные значения, но ухудшает типобезопасность: при чтении придётся выполнять динамические проверки и приведения.

Вариант с [Int] не подходит, потому что он не может хранить отсутствие значения. Выбранный [Int?] явно фиксирует контракт: каждый элемент либо содержит Int, либо равен nil. Это сохраняет статическую проверку и позволяет отдельно применить compactMap, если позже потребуется отбросить отсутствующие элементы.

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

Почему массив не получает тип [Any] автоматически?

Swift выбирает наиболее конкретный совместимый тип, а не произвольно поднимает все элементы до Any. Для 1 и nil таким типом является Optional<Int>, поэтому [Int?] точнее и полезнее, чем [Any].
Что изменится, если внешний контекст задаст Int32?

Литерал 1 будет интерпретирован как Int32, а nil — как отсутствие значения типа Int32. В результате получится [Int32?]. Тип литерала определяется не только самим числом, но и доступным контекстом.
Почему массив только из nil нельзя вывести без аннотации?

nil не содержит сведений о типе Wrapped. Поэтому компилятор не знает, должен ли результат быть [Int?], [String?] или, например, [SomeClass?]. Нужен контекст вроде явной аннотации типа или параметра функции, который задаёт конкретный тип элементов.