On 17 October 2022 12:38:32 BST, "Peter Sommerlad (C++) via Std-Proposals" <std-proposals@lists.isocpp.org> wrote:
>FWIW, MISRA-C++ and me propose to define (copy/move) assignment
>operators to be lvalue-ref-qualified, at least when you must define
>those, because you are implementing a manager type. This is in line with
>"when in doubt, do as the ints do" (Scott Meyers), because with the
>fundamental types you cannot assign to an rvalue.
I think this is a disciplined take for value types, but for reference types it might not be adequate.
I think Peter accounted for reference types by saying "Note, that I don't propose [...] or potentially return an lvalue reference to an rvalue [...]" below what you replied to.
FWIW, I think the extra `&` (multiplied by all the types in your program) is just noise. Also, what, this means you can't use the Rule of Zero anymore because it won't append that superfluous `&`? That's much more noise, and potential for introducing errors accidentally. So, I disagreed with MISRA-C++'s proposed guideline there.
>my classical example of leaking lvalue references is:
>
>struct X{};
>
>auto & dangle = (X{} = X{});
The main issue here seems to be to return a reference from the assignment at all. And if `rvalue = something` returns a reference, it should better be an rvalue reference. If the object is expiring, then it is still expiring after you assign to it.
Or unless it's lifetime-extended. ;) Totally tangential, but I have a blog post on that corner case:
Cheers,
Arthur