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

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

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

Абстракции Sequence и IteratorProtocol отделяют описание последовательности от способа её обхода. Это позволяет работать единообразно с массивами, ленивыми последовательностями, потоками данных и одноразовыми источниками, не раскрывая их внутреннее хранилище.

Такой подход требует явного объекта состояния обхода — итератора. Поскольку протокол не задаёт универсальную семантику копирования этого состояния, конкретная реализация сама определяет, что означает копия.

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

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

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

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

Метод next() изменяет состояние итератора и возвращает следующий элемент либо nil, когда обход завершён. Протокол требует поддерживать такой переход состояния, но не устанавливает правила для присваивания итератора другой переменной.

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

Минимальный пример возможного общего состояния:

final class State {
    var value = 0
}

struct SharedIterator: IteratorProtocol {
    let state: State

    mutating func next() -> Int? {
        guard state.value < 3 else { return nil }
        defer { state.value += 1 }
        return state.value
    }
}

var first = SharedIterator(state: State())
var second = first
print(first.next() as Any)  // Optional(0)
print(second.next() as Any) // Optional(1)

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

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

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

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

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

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

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

Означает ли копирование итератора копирование текущего элемента?

Нет. Итератор обычно хранит позицию или состояние, а не «текущий элемент» как отдельную гарантию протокола. Вызов next() может вычислить значение на лету, обратиться к внешнему ресурсу или изменить внутреннее состояние; протокол не требует конкретного представления текущего элемента.

Можно ли сравнивать два итератора по их позиции?

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

Гарантирует ли повторный вызов next() после nil стабильный результат?

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