почему встроенное присваивание возвращает неконстантную ссылку вместо константной ссылки в С++?

По замыслу одно фундаментальное различие между C и C++ заключается в том, что C — это язык отбрасывающий lvalue, а C++ — сохраняющий lvalue.

До C++98 Бьерн добавил ссылки на язык, чтобы сделать возможной перегрузку операторов. А ссылки, чтобы быть полезными, требуют, чтобы ценность выражений сохранялась, а не отбрасывалась.

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

C++ стремится сохранить "lvalueness" любого результата выражения, пока это возможно. Это относится ко всем встроенным операторам, а также к встроенному оператору присваивания. Конечно, это не делается для того, чтобы можно было записывать такие выражения, как (a = b) = c, поскольку их поведение было бы неопределенным (по крайней мере, в исходном стандарте C++). Но из-за этого свойства C++ вы можете написать такой код, как

int a, b = 42;
int *p = &(a = b);

Насколько это полезно — другой вопрос, но опять же, это лишь одно из следствий сохранения lvalue дизайна выражений C++.

Что касается того, почему это не const lvalue... Честно говоря, я не понимаю, почему это должно быть. Как и любой другой встроенный оператор, сохраняющий lvalue в C++, он просто сохраняет любой заданный ему тип.

Отвечу на вопрос в заголовке.

Предположим, что он вернул ссылку rvalue. Таким образом было бы невозможно вернуть ссылку на вновь назначенный объект (потому что это lvalue). Если невозможно вернуть ссылку на вновь назначенный объект, необходимо создать копию. Это было бы ужасно неэффективно для тяжелых предметов, например контейнеров.

Рассмотрим пример класса, похожего на std::vector.

С текущим типом возвращаемого значения назначение работает следующим образом (я намеренно не использую шаблоны и идиому копирования и замены, чтобы сделать код максимально простым):

class vector {
     vector& operator=(const vector& other) {
         // Do some heavy internal copying here.
         // No copy here: I just effectively return this.
         return *this;
     }
};

Предположим, что он вернул rvalue:

class vector {
     vector operator=(const vector& other) {
          // Do some heavy stuff here to update this. 
          // A copy must happen here again.
          return *this;
      }
};

Вы можете подумать о возврате ссылки на rvalue, но это тоже не сработает: вы не можете просто переместить *this (иначе цепочка присвоений a = b = c запустит b), поэтому для ее возврата также потребуется вторая копия.

Вопрос в теле вашего сообщения другой: возврат const vector& действительно возможен без каких-либо осложнений, показанных выше, поэтому для меня это больше похоже на соглашение.

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

Встроенные операторы ничего не "возвращают", не говоря уже о "возвращении ссылки".

Выражения характеризуются в основном двумя вещами:

• их тип
• их стоимостная категория.

Например, k + 1 имеет тип int и категорию значения "prvalue", а k = 1 имеет тип int и категорию значения "lvalue". lvalue — это выражение, обозначающее ячейку памяти, а ячейка, обозначенная k = 1, — это та же ячейка, которая была выделена объявлением int k;.

Стандарт C имеет только категории значений "lvalue" и "not lvalue". В C k = 1 имеет тип int и категорию "не lvalue".

Кажется, вы предлагаете, чтобы k = 1 имел тип const int и категорию значений lvalue. Возможно, можно было бы, язык был бы немного другим. Это поставило бы вне закона запутанный код, но, возможно, запретил бы и полезный код. Это решение трудно оценить разработчику языка или комитету по разработке, потому что они не могут придумать все возможные способы использования языка.

Они ошибаются в том, что не вводят ограничений, которые могут оказаться проблемой, которую еще никто не предвидел. Связанный пример: Должны ли неявно сгенерированные операторы присваивания быть & ref-квалифицированными? .

void foo(int& x);

int y;
foo(y = 3);