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

> Hi,
>
> 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.
>
> >
> >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.
>

But we write the copy assignment operator as X& X::X(X&), and the move
assignment operator as X&& X::X(X&&); the implicit object parameter is not
ref-qualified, so it can accept any value category, but for historical
reasons it always returns lvalue. And this is what the
automatically-generated assignment operators do as well.

Are you proposing to double the number of required/supported assignment
operator overloads? Or should the compiler propagate value category from
the LHS of an assignment to class type to its result (if the selected
member assignment operator is not ref-qualified)? After all, the returned
reference may be a different object to the implicit object argument (the
LHS).

>
> >That we have unqualified member functions like front/back on containers
> >that could be called on rvalues and deliver lvalue references is a pity,
> >but that is something where changing the library to delete the
> >rvalue-qualified overload or make it return by value might be too much
> work.
> >
> >But for my own types I'll follow the practice of ref-qualifying member
> >functions with side effects and returning references to guts accordingly.
> >
> >I don't know yet, how that will change with deducing this in C++23.
> >
> >Note, that I don't propose all overloads of any assignment operator to
> >be lvalue-ref-qualified, because a type might be defining a DSL where
> >such things might not have side effects or potentially return an lvalue
> >reference to an rvalue.
> >
> >Regards
> >Peter.
>
> Cheers,
> Lénárd
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>