To what end? Non-const lvalue references have those limitations *for a
reason*. The C++ committee wouldn't take them away even if backwards
compatibility weren't an issue.

Well I don't know, even Visual Studio used to lessen that restriction:

https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4350?view=msvc-170

So it's not essential.

In any case my own personal goal is to simplify the syntax as much as possible to make the code readable and maintainable. There are cases you'd want to disregard the output variable as well, and this is my no mean the called function's concern. Ex:

Input code:

void foo(ostream & log);

...

Converted code:

void foo(ostream && log);

...

foo(move(ostream()));

Again my own personal goal is to keep the code as simple and clean as possible to ease code maintenance over long term. I know from experience this is not a bad thing.

By taking a non-const lvalue reference, a function is advertising that
the parameter is also an output value. That the function intends to
modify that value, and that the modification is significant and
meaningful to the caller.

That's a gray area. Just like the "mutable" keyword that "should" only be used for things like cache, but was really useful and efficient back in the auto_ptr<> days:

https://lists.boost.org/Archives/boost//2003/07/49586.php

https://github.com/philippeb8/fcalc/blob/master/include/mutable_ptr.h

Or like the "auto" keyword that shouldn't be used to declare member variables (yet "decltype()" does exactly the same thing).

That's why we don't allow people to use rvalues with them. An rvalue
expression is not (in theory) supposed to be used after the expression
in which it appears. Therefore, nobody will see the modifications
caused by the non-const lvalue reference-taking function. And since
the function clearly stated that those modifications are
significant... the caller made a mistake.

By taking a non-const rvalue reference, a function is advertising that
it will modify the object, but it *does not expect* the user to care
about those modifications. That is, it is modifying the object in a
way that will render the object's state non-useful to the caller.

Demolishing the distinction between lvalue and rvalue reference
parameters is... unhelpful. You can no longer tell if a function
intends to output to a value or intends to just corrupt the value.

Furthermore, your code is now nonsensical. If you ever see code of the
form `function_name(std::move(object));` that is an indication that
`object` should not be used from that point forward (or should be
reset to a legitimate value). By forcing a user to "move" even when
they're not moving anything, you take away the original intent of the
code.

std::move() states that an object *may* be moved from:

https://en.cppreference.com/w/cpp/utility/move

So it essentially doesn't mean anything "legally" speaking.

--

Phil Bouchard CTO T: (819) 328-4743 E: phil@fornux.com | www.fornux.com 8 rue de la Baie | Gatineau (Qc), J8T 3H3 Canada

Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.