On Mon, Oct 17, 2022 at 12:31 PM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 17 October 2022 12:38:32 BST, "Peter Sommerlad (C++) via Std-Proposals"
> <std-proposals_at_[hidden]> 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:
https://quuxplusone.github.io/blog/2022/07/09/lifetime-extended-assignments/

Cheers,
Arthur