On 1/6/23 12:50, Jason McKesson wrote:
>
> 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);

...

foo(ostream());


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.

-- 
Email Signature
Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon 
<https://www.linkedin.com/in/phil-bouchard-5723a910/>
CTO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
Banner <https://goglobalawards.org/> 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.