ref-квалификаторы для оператора присваивания типов стандартных библиотек

Мне было интересно, есть ли причина, по которой оператор присваивания стандартных типов не имеет lvalue ref-qualified? Ни один из них.

Из-за этого мы можем писать такие вещи, как это:

std::string{} = "42";
std::string s = "hello " + std::string{"world"} = "oops!";

std::vector<int> v = { 1,2,3 };
std::move(v) = { 4,5,6 };

Если бы оператор присваивания был квалифицирован как lvalue ref, все эти примеры не скомпилировались бы.

Это потому, что есть много вещей, которые нужно изменить (но тогда это было для noexcept), и никто не написал предложение? Я не думаю, что люди пишут такой код, но разве библиотека не должна быть спроектирована так, чтобы она даже этого не позволяла?


person Marius Bancila    schedule 26.10.2018    source источник


Ответы (1)


Ваше предложение было предложено в 2009 г. , и в конечном итоге отклонен во Франкфурте в том же году из-за " опасения по поводу обратной совместимости".

Это было бы кардинальным изменением, а нам это не нравится.

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

Была бы библиотека спроектирована таким образом, если бы у нас был чистый лист? Возможно.

person Lightness Races in Orbit    schedule 26.10.2018
comment
Ба, просто лиши его права, подожди 6 лет и убей его. 99/100 использований будут ошибками. - person Yakk - Adam Nevraumont; 26.10.2018
comment
Я понимаю. Но что бы это сломало? Что-то большее, чем некоторые нишевые случаи? - person Marius Bancila; 26.10.2018
comment
@MariusBancila Нет, это почти так, и Адам прав. Но все равно. Мне кажется идеальным кандидатом на то, что мы думали, это не стоило неожиданной катастрофы, которая последовала за ситуацией через несколько лет. Я думаю, не стоит чинить то, что не полностью и полностью сломано. - person Lightness Races in Orbit; 26.10.2018