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

Обычное копирующее присваивание для класса с нестатическим членом const типа int компилятор объявляет, но определяет как удалённое. Причина в том, что присваивание объекта выполняется поэлементно, а значение const-члена после инициализации изменить нельзя.

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

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

C++ поддерживает автоматическое создание специальных функций-членов, чтобы типы с обычными полями можно было использовать как значения без ручного написания копирования и присваивания. Такой подход уменьшает количество шаблонного кода и лежит в основе правила нуля.

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

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

Рассмотрим объект с постоянным идентификатором и изменяемым состоянием. Копирующее присваивание вроде left = right должно заменить значения всех присваиваемых полей объекта left, но его const-идентификатор менять нельзя.

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

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

При копирующем присваивании компилятор концептуально присваивает каждый нестатический член отдельно. Для обычного целочисленного поля это допустимо, а для const int — нет: после инициализации оно не может стать другим значением.

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

struct Record {
    const int id;
    int value;

    Record(int i, int v) : id(i), value(v) {}
    Record& operator=(const Record&) = default;
};

Record first{1, 10};
Record second{2, 20};
first = second; // ошибка: оператор присваивания удалён

Конструктор копирования работает иначе: он создаёт новый объект и инициализирует его id значением исходного объекта. Изменения существующего id при этом нет.

Можно явно удалить присваивание, чтобы выразить намерение типа. Если объект должен быть присваиваемым, обычно const убирают с поля и обеспечивают неизменность идентификатора через интерфейс или выбирают другую модель данных.

Иногда допустимо написать пользовательский оператор присваивания, который копирует только изменяемые поля и сохраняет id. Но это уже не обычное поэлементное присваивание: нужно документировать, что идентификатор назначения намеренно не меняется. Использование const_cast для изменения const-члена не является корректным способом решения.

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

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

Первый вариант — оставить const у id и пользоваться только конструктором копирования. Плюс такого решения — инвариант идентификатора защищён на уровне типа; минус — нельзя применять обычное присваивание.

Второй вариант — реализовать оператор присваивания, копирующий баланс и статус, но не трогающий id. Это сохраняет идентичность объекта, однако операция уже означает не полную замену аккаунта, а перенос его изменяемого состояния.

Третий вариант — сделать id обычным полем с закрытым доступом и запретить его изменение публичным интерфейсом. Это позволяет сохранить присваиваемость, но защита становится частью пользовательской семантики класса, а не непосредственным ограничением типа.

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

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

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

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

Да, оператор можно определить вручную, но он не сможет присвоить новое значение const-члену. Он может скопировать остальные поля, проверить совпадение идентификаторов или намеренно сохранить идентификатор объекта назначения. Поэтому наличие пользовательского оператора не делает возможной полную замену состояния автоматически — семантику нужно реализовать явно.
Почему const_cast не является исправлением ошибки присваивания?

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