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

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

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

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

reduce возник как обобщённый способ свернуть последовательность значений в один результат: число, строку, структуру или объект-агрегатор. Такой подход переносит логику обхода в библиотечный метод, а разработчик описывает только переход от текущего результата к следующему.

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

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

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

Это создаёт побочные эффекты, усложняет тестирование и особенно опасно при повторном использовании исходного объекта или при обработке, которая может завершиться ошибкой. Для структуры такой эффект обычно отсутствует: изменение локальной копии не меняет исходное значение напрямую.

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

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

Для экземпляра класса значением аккумулятора является ссылка. Копирование этой ссылки увеличивает число ссылок на тот же объект, но не копирует его хранимые свойства. Поэтому операция изменения свойства через параметр замыкания меняет общий объект:

final class Statistics {
    var sum = 0
}

let statistics = [1, 2, 3].reduce(Statistics()) { result, value in
    result.sum += value
    return result
}

let alias = statistics
print(statistics.sum)       // 6
print(alias === statistics) // true

Параметр result может быть объявлен как let: запрещено переназначить саму ссылку, но разрешено изменить состояние объекта, на который она указывает. return result возвращает ту же ссылку, поэтому следующий шаг продолжает работать с тем же экземпляром.

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

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

Практическое следствие: reduce с классом может намеренно использовать общее изменяемое состояние, но это делает функцию менее чистой. Если нужен локальный изменяемый сборщик, чаще выбирают reduce(into:) или обычный цикл; если важна ссылочная идентичность, класс оправдан только при ясном контроле владения и побочных эффектов.

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

Сервис собирает статистику по событиям и должен обновить объект, который уже передан нескольким компонентам приложения. Возможны три варианта.

Класс-аккумулятор в reduce сохраняет идентичность объекта, поэтому все держатели ссылки увидят обновлённые свойства. Минус — скрытый побочный эффект и необходимость учитывать совместный доступ к состоянию.
Структура в reduce изолирует промежуточные значения и лучше соответствует функциональному стилю. Минус — после завершения нужно явно передать новый результат заинтересованным компонентам.
Обычный цикл проще отлаживать и явно показывает мутацию. Минус — обход и логика накопления оказываются менее декларативными, а общий объект всё равно требует контроля доступа.

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

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

Вопрос: Может ли reduce вернуть другой экземпляр класса на середине обхода?

Ответ: Да. Аккумулятор имеет тип класса, но это не означает неизменную идентичность объекта. Замыкание может создать новый экземпляр и вернуть его; последующие итерации получат ссылку на новый объект. Внешние ссылки на прежний экземпляр останутся прежними.
Вопрос: Что произойдёт с объектом-аккумулятором, если throwing-замыкание завершит reduce ошибкой после нескольких итераций?

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

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