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

Нет. Итератор std::set предоставляет доступ к ключу как к константному значению, поэтому изменить его напрямую нельзя. Это защищает упорядоченность дерева; для безопасной замены ключа нужно удалить элемент и вставить новый либо использовать узел-обработчик через extract в C++17.

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

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

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

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

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

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

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

У std::set тип value_type совпадает с типом ключа, но элементы доступны через константный интерфейс. Это не означает, что сам контейнер нельзя изменять: можно удалять элементы и добавлять новые, однако уже размещённый ключ нельзя менять напрямую.

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

Начиная с C++17, можно извлечь узел методом extract, изменить его значение вне контейнера и вставить обратно:

#include <set>
#include <utility>

int main() {
    std::set<int> values{1, 3, 5};
    auto it = values.find(3);

    auto node = values.extract(it);
    node.value() = 4;
    values.insert(std::move(node));
}

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

У std::set нельзя рассчитывать на сохранение итератора извлечённого элемента: после extract этот итератор больше не следует использовать. Если вставка изменённого узла не удалась, например из-за уже существующего эквивалентного ключа, результат вставки нужно проверить; не вставленный узел возвращается в результате операции и может быть обработан отдельно.

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

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

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

Был выбран extract и последующая вставка изменённого узла. Это сохранило сам узел и его ресурсы, но потребовало C++17 и обязательной проверки результата вставки на конфликт ключей. В итоге операция стала безопасной и не нарушила упорядоченность контейнера.

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

Почему изменение значения элемента в std::map иногда разрешено, хотя изменение ключа запрещено?

В std::map элемент имеет тип, логически разделяющий ключ и отображаемое значение. Ключ доступен как константная часть пары, потому что он определяет положение узла в дереве, а mapped_type можно изменять. Изменение отображаемого значения не меняет порядок элементов и потому не нарушает инварианты контейнера.

Что произойдёт, если новый ключ эквивалентен уже существующему?

В std::set эквивалентные ключи не дублируются. В таком случае вставка извлечённого узла не будет успешной; это нужно определить по результату insert. Сам узел не следует терять: результат операции содержит его, если контейнер не принял узел, поэтому программу можно вернуть к старому ключу, перенести данные в другой контейнер или выполнить альтернативную обработку.

Почему нельзя изменить ключ через const_cast, даже если после этого вручную восстановить порядок?

Константность является частью контракта интерфейса контейнера, а не временной рекомендацией. Объект, доступный как константный элемент std::set, нельзя легально модифицировать снятием const; такое действие нарушает правила языка и может привести к неопределённому поведению. Кроме того, контейнер не предоставляет операции для безопасного ручного восстановления внутренних связей дерева, поэтому правильный путь — extract либо удаление с последующей вставкой.