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

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

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

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

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

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

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

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

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

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

var values = [10, 20, 30]
let index = values.index(before: values.endIndex)

values.removeLast()
let value = values[index] // Ошибка выполнения: индекс равен endIndex

До удаления index указывал на элемент 30. После удаления он стал равен новому endIndex, поэтому индекс больше не обозначает элемент. В других случаях индекс может остаться численно допустимым, но начать обозначать другой элемент.

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

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

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

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

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

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

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

Можно ли считать индекс стабильным идентификатором элемента?

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

Помогает ли замена индекса на целочисленное смещение?

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

Всегда ли любая мутация немедленно делает все индексы недействительными?

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