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

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

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

Правило definite initialization появилось как часть общей модели безопасности Swift: чтение неинициализированной памяти должно быть невозможно на уровне компиляции. Языку не нужно полагаться на случайное начальное содержимое памяти или вставлять неочевидные значения по умолчанию для локальных переменных.

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

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

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

func makeValue(shouldAssign: Bool) -> Int {
    var result: Int

    while shouldAssign {
        result = 42
        break
    }

    return result // Ошибка: result может быть не инициализирована
}

Если такое чтение разрешить, при shouldAssign == false функция попыталась бы вернуть значение, которому ничего не присвоили. Это нарушило бы гарантию безопасности Swift.

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

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

Присваивание до цикла устраняет проблему:

func makeValue(shouldAssign: Bool) -> Int {
    var result = 0

    while shouldAssign {
        result = 42
        break
    }

    return result
}

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

Ключевое различие — между инициализацией и изменением. Объявление переменной без значения требует доказать первое присваивание на каждом пути; после этого обычные присваивания проверяются уже как мутация существующего значения.

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

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

Сервис выбирает конфигурацию в цикле поиска. Разработчик объявляет результат без начального значения и присваивает его при первом найденном элементе. Если список пуст или условие поиска не сработало, результат остаётся неинициализированным.

Вариант с принудительным значением по умолчанию компилируется, но может скрыть ошибку: невозможно отличить «найдено значение по умолчанию» от «ничего не найдено». Optional лучше отражает такую неопределённость, но требует обработки nil.

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

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

Вопрос: Почему присваивание переменной в обеих ветвях условного оператора обычно делает её доступной после условного оператора?

Ответ: Потому что компилятор видит, что независимо от результата условия выполнится ровно одна из ветвей и каждая ветвь завершает инициализацию переменной. Если существует путь, например ветвь без присваивания или ранний переход до него, чтение после условия будет запрещено.
Вопрос: Чем отличается повторное присваивание от инициализации при анализе локальной переменной?

Ответ: Первое присваивание создаёт допустимое значение переменной, а последующие присваивания заменяют уже существующее значение. До первой инициализации нельзя читать переменную и нельзя считать её безопасной только из-за объявления. После инициализации компилятор проверяет уже другие правила, включая тип, доступность и эксклюзивность доступа.
Вопрос: Почему присваивание внутри бесконечного цикла не всегда позволяет считать переменную инициализированной после цикла?

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