func ==(lhs: MyStructure, rhs: MyStructure) -> Bool {
    return lhs.hashValue == rhs.hashValue
}

Обратите внимание на глобальную функцию для перегрузки оператора равенства (==), чтобы соответствовать протоколу Equatable, который требуется для протокола Hashable.

Ваша проблема - неправильная реализация равенства.

Для хэш-таблицы (такой как Swift Dictionary или Set) требуются отдельные реализации равенства и hash.

hash приближает вас к объекту, который вы ищете; равенство дает вам именно тот объект, который вы ищете.

Ваш код использует ту же реализацию для hash и равенства, и это гарантирует коллизию.

Чтобы решить эту проблему, реализуйте равенство для соответствия точным значениям объекта (однако ваша модель определяет равенство). Например.:

func ==(lhs: MyStructure, rhs: MyStructure) -> Bool {
    return lhs.id == rhs.id
}

Я думаю, у вас есть все необходимые кусочки головоломки - вам просто нужно собрать их воедино. У вас есть множество отличных источников.

Коллизии хэшей в порядке. Если возникает конфликт хешей, вместо этого объекты будут проверяться на равенство (только по отношению к объектам с совпадающими хэшами). По этой причине соответствие объектов Equatable должно основываться на чем-то другом, кроме hashValue, если вы не уверены, что хеши не могут конфликтовать.

Это точная причина того, что объекты, соответствующие Hashable, также должны соответствовать Equatable. Swift нужен более специфичный для предметной области метод сравнения, когда хеширование не помогает.

В той же статье NSHipster вы можете увидеть, как Мэтт реализует isEqual: по сравнению с hash в своем примере Person класса. В частности, у него есть isEqualToPerson: метод, который проверяет другие свойства человека (дата рождения, полное имя) для определения равенства.

- (BOOL)isEqualToPerson:(Person *)person {
  if (!person) {
    return NO;
  }

  BOOL haveEqualNames = (!self.name && !person.name) || [self.name isEqualToString:person.name];
  BOOL haveEqualBirthdays = (!self.birthday && !person.birthday) || [self.birthday isEqualToDate:person.birthday];

  return haveEqualNames && haveEqualBirthdays;
}

Он не использует хеш-значение при проверке равенства - он использует свойства, специфичные для его класса людей.

Точно так же Swift не позволяет вам просто использовать объект Hashable в качестве словарного ключа - неявно, посредством наследования протокола - ключи также должны соответствовать Equatable. Для стандартных библиотечных типов Swift об этом уже позаботились, но для ваших пользовательских типов и классов вы должны создать свою собственную == реализацию. Вот почему Swift не обрабатывает автоматически конфликты словаря с пользовательскими типами - вы должны реализовать Equatable самостоятельно!

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

if person1 === person2 {
    // ...
}

Здесь нет гарантии, что person1 и person2 имеют разные свойства, просто они занимают отдельное место в памяти. И наоборот, в более раннем методе isEqualToPerson: нет гарантии, что два человека с одинаковыми именами и датами рождения на самом деле являются одними и теми же людьми. Таким образом, вы должны подумать о том, что имеет смысл для конкретного типа объекта. Опять же, еще одна причина, по которой Swift не реализует Equatable за вас на пользовательских типах.

равные значения хэша приводят к перезаписи ключа collision1 ключом collision2. Предупреждения нет. Если такое столкновение произошло только один раз в словаре со 100 ключами, то его легко можно было бы пропустить.

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

Dictionary операции работают над равенством (==) ключей. Словари не содержат повторяющихся ключей (т. Е. Одинаковых ключей). Когда вы устанавливаете значение с помощью ключа, он перезаписывает любую запись, содержащую одинаковый ключ. Когда вы получаете запись с нижним индексом, она находит значение с ключом, который равен, но не обязательно такой же, как то, что вы указали. И так далее.

collision1 и collision2 равны (==) в зависимости от того, как вы определили оператор ==. Следовательно, установка записи с ключом collision2 должна перезаписать любую запись с ключом collision1.

P.S. То же самое и со словарями на других языках. Например, в Какао NSDictionary не позволяет дублировать ключи, то есть ключи, которые имеют isEqual:. В Java Maps не допускают дублирования ключей, т. Е. Ключей .equals().

_{Вы можете увидеть мои комментарии к ответам на этой странице и этот ответ. Я думаю, что все ответы по-прежнему написаны ОЧЕНЬ запутанно.}

tl; dr 0) вам не нужно писать реализацию isEqual, т.е. == между hashValues. 1) Только предоставить / вернуть hashValue. 2) просто реализуйте Equatable, как обычно

0) Чтобы соответствовать hashable, вы должны иметь вычисленное значение с именем hashValue и присвоить ему соответствующее значение. В отличие от equatable протокола, сравнение hashValues ​​уже существует. Вам НЕ нужно писать:

func ==(lhs: MyStructure, rhs: MyStructure) -> Bool {
    return lhs.hashValue == rhs.hashValue
    // Snippet A
}

1) Затем он использует hashValue, чтобы проверить, существует ли для этого индекса hashValue (рассчитанного по модулю против счетчика массива) просматриваемый ключ или нет. Он просматривает массив пар ключ / значение этого индекса.

2) Однако в качестве отказоустойчивого, т. е. в случае совпадения хешей, вы возвращаетесь к обычной функции ==. (Логически он вам нужен из-за отказоустойчивости. Но он вам также нужен, потому что протокол Hashable соответствует Equatable, и поэтому вы должны написать реализацию для ==. В противном случае вы получите ошибку компилятора)

func == (lhs: MyStructure, rhs: MyStructure) -> Bool {
    return lhs.id == rhs.id
    //Snippet B
}

Вывод:

Вы должны включить фрагмент B, исключить фрагмент A, но при этом иметь свойство hashValue