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

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

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

Set обычно реализуется на основе хеш-таблицы. Хеш позволяет быстро определить область, где должен находиться элемент, а == подтверждает точное совпадение.

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

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

Если hash(into:) зависит от изменяемого свойства, объект после мутации начинает соответствовать другой позиции хеш-таблицы. Физически он может остаться в старой позиции, тогда как поиск будет выполняться уже по новому хешу.

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

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

Контракт Hashable требует, чтобы равные значения имели одинаковый хеш. Практически это означает, что свойства, участвующие в == и hash(into:), нельзя менять, пока значение находится в Set.

final class User: Hashable {
    var id: Int

    init(id: Int) {
        self.id = id
    }

    static func == (lhs: User, rhs: User) -> Bool {
        lhs.id == rhs.id
    }

    func hash(into hasher: inout Hasher) {
        hasher.combine(id)
    }
}

let user = User(id: 1)
var users: Set<User> = [user]
user.id = 2

После изменения id поиск user может использовать хеш для значения 2, хотя объект был размещён при хеше для значения 1. Нельзя полагаться на успешные результаты contains, remove или вставки после такого изменения.

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

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

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

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

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

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

1. Достаточно ли, чтобы изменился только результат hash(into:), если == остался прежним?

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

2. Можно ли включать в Hashable ссылочное поле объекта?

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

3. Почему нельзя решить проблему вызовом update(with:) после мутации объекта?

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