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

Целочисленный литерал в Swift не обязан заранее иметь фиксированный тип. Его тип выводится из контекста: если контекста нет, обычно выбирается Int, а при явном ожидаемом типе литерал проверяется на возможность представить это значение в нём.

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

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

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

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

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

Например, значение может подходить для Int8, но литерал, выходящий за диапазон этого типа, будет отвергнут компилятором. Это отличается от неявного преобразования: Swift не должен молча обрезать или менять значение.

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

Если литерал используется без дополнительного контекста, Swift по умолчанию выводит для него тип Int. Если тип ожидается из объявления переменной, параметра или другого выражения, литерал проверяется и может получить этот тип.

let defaultValue = 1        // Int
let byteValue: Int8 = 1     // Int8
let wideValue: Int64 = 1    // Int64
let invalid: UInt8 = 300    // ошибка компиляции: значение вне диапазона

Важное следствие: присваивание литерала переменной типа Int8 не является преобразованием уже созданного значения Int в Int8. Компилятор сразу проверяет, может ли литерал быть представлен целевым типом.

Для переменных это правило работает иначе, поскольку переменная уже имеет конкретный тип. Значение типа Int нельзя без явного преобразования передать туда, где требуется Int8, даже если фактическое число находится в допустимом диапазоне.

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

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

Библиотека принимает размер буфера как UInt32, а разработчик передаёт числовой литерал. Для небольшого константного значения такой вызов может корректно типизироваться по ожидаемому типу, но вычисленное заранее значение типа Int потребует явного преобразования.

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

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

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

Является ли литерал типа Int до анализа контекста?

Нет. Литерал — это специальное выражение, поддерживающее вывод подходящего целевого типа. Int является его типом по умолчанию только тогда, когда другой контекст не задаёт тип.

Почему значение типа Int нельзя безопасно передать туда, где ожидается Int8, даже если число маленькое?

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

Может ли контекст привести к ошибке компиляции, хотя сам литерал выглядит корректным?

Да. Если ожидаемый тип не поддерживает нужный литеральный формат или значение не входит в его диапазон, компилятор отклонит выражение. Это происходит во время компиляции, а не как неожиданное переполнение при выполнении программы.