Arthur I disagree, anything of the form "func() = ..." or is just bad
form & absolutely confusing to newbies, even if it's syntactically
correct it's bad practice and you know it. Better to depreciate &
declare it an error than to allow that practice to continue. The
result of a function should ALWAYS be an rvalue to avoid confusion and
poorly thought out code.

On Fri, 7 Oct 2022 at 23:47, Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Fri, Oct 7, 2022 at 8:21 AM blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> N2819 was rejected on the grounds that (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 [...]
>
> EWG said they rejected it "because of concerns about backwards compatibility," and I believe them.
> IIUC you're proposing to take this code, valid in C++98-through-C++23,
> struct BitReference {
> void operator=(bool);
> };
> BitReference vectorFront();
> void test() {
> vectorFront() = true;
> }
> and make it give a compiler error instead. That's no good.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals