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

Если в Set уже есть элемент, равный добавляемому по Hashable и Equatable, вставка не изменяет множество: компонент inserted равен false, а memberAfterInsert содержит уже сохранённый экземпляр. Если эквивалентного элемента нет, элемент добавляется, inserted равен true, а второй компонент содержит добавленный элемент.

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

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

Поэтому API Set возвращает одновременно факт вставки и элемент, который фактически находится в множестве после операции. Это позволяет использовать множество как хранилище канонических экземпляров.

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

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

Нельзя трактовать inserted == false как ошибку операции. Это нормальный результат, означающий, что множество уже содержало эквивалентный элемент и сохранило прежнее значение.

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

Метод insert сначала использует хеш элемента для выбора области поиска, а затем проверяет равенство кандидатов через ==. Совпадение хеша само по себе не доказывает равенство: разные элементы могут иметь одинаковый хеш.

Результат содержит два значения:

inserted — был ли добавлен новый элемент;
memberAfterInsert — элемент, фактически представленный в множестве после операции.

struct User: Hashable {
    let id: Int
    let name: String
}

var users: Set = [User(id: 1, name: "Анна")]
let result = users.insert(User(id: 1, name: "Аня"))

print(result.inserted)              // false
print(result.memberAfterInsert.name) // Анна

В примере оба значения равны по id только в том случае, если реализация Hashable и Equatable определяет равенство по id. Для автоматически синтезированных реализаций Swift учитывает все хранимые свойства, поэтому в таком виде элементы с разными именами обычно не будут равны. Чтобы пример отражал канонизацию по идентификатору, равенство нужно определить явно:

struct User: Hashable {
    let id: Int
    let name: String

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

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

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

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

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

Вариант с безусловным insert проще, но без анализа результата можно случайно потерять данные загруженного экземпляра. Выбранное решение — проверить inserted, а при false использовать memberAfterInsert: это выполняет операцию за один логический поиск и явно сохраняет уже канонический объект.

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

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

Достаточно ли совпадения хешей для отказа во вставке?

Нет. Совпадение хешей означает только, что элементы попали в одну область поиска. Затем Set обязан проверить равенство через ==. Если хеши совпали, но элементы не равны, оба элемента могут находиться в множестве.
Что именно возвращает memberAfterInsert, если вставка не состоялась?

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

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