Date: Fri, 7 Oct 2022 20:20:59 +0800
N2819 <https://wg21.link/N2819> was rejected on the grounds that (N2920
<https://wg21.link/N2920>):
N2819, "N2819 Ref-Qualifiers for assignment operators of the Standard
Library" was initially considered by the LWG. This proposal sought to
change 350 copy-assignment operators in the C++ standard library to prevent
assignment operations in which the left operand is an rvalue. Due to the
large number of changes required, the proposal was sent to EWG, with the
request that the default behavior for implicit copy-assignment operators be
reconsidered, so that assignment to an rvalue is not permitted. The EWG
resolved to maintain the status quo, because of concerns about backwards
compatibility.
I think one reason EWG rejected it is that even if the assigned value is
later lost, the assignment might have other side effects that are
preserved. However, there are rare cases where rvalues are assigned for
side effects. Apart from those included in the proposal, I can only think
of std::ostream_iterator and std::ostreambuf_iterator. If someone really
wants to do rvalue assignment, the as_lvalue function template can be added
to the standard to make it work (from https://stackoverflow.com/a/29041656/)
:
template<class T>
std::remove_reference_t<T>& as_lvalue(T&&t){return t;}
Another reason is that the work is too onerous. It can be addressed by
having the assignment operator include a ref-qualifier by default, but a
syntax is required to cancel it.
I think the same applies to the compound assignment operators, too. Does
that create new issues?
<https://wg21.link/N2920>):
N2819, "N2819 Ref-Qualifiers for assignment operators of the Standard
Library" was initially considered by the LWG. This proposal sought to
change 350 copy-assignment operators in the C++ standard library to prevent
assignment operations in which the left operand is an rvalue. Due to the
large number of changes required, the proposal was sent to EWG, with the
request that the default behavior for implicit copy-assignment operators be
reconsidered, so that assignment to an rvalue is not permitted. The EWG
resolved to maintain the status quo, because of concerns about backwards
compatibility.
I think one reason EWG rejected it is that even if the assigned value is
later lost, the assignment might have other side effects that are
preserved. However, there are rare cases where rvalues are assigned for
side effects. Apart from those included in the proposal, I can only think
of std::ostream_iterator and std::ostreambuf_iterator. If someone really
wants to do rvalue assignment, the as_lvalue function template can be added
to the standard to make it work (from https://stackoverflow.com/a/29041656/)
:
template<class T>
std::remove_reference_t<T>& as_lvalue(T&&t){return t;}
Another reason is that the work is too onerous. It can be addressed by
having the assignment operator include a ref-qualifier by default, but a
syntax is required to cancel it.
I think the same applies to the compound assignment operators, too. Does
that create new issues?
Received on 2022-10-07 12:21:30