rvalues -> ref (yup... again!)

[Nick Sabalausky (Abscissa)]

On 03/24/2018 03:03 AM, Jonathan M Davis wrote:
> On Saturday, March 24, 2018 01:37:10 Nick Sabalausky  via Digitalmars-d
> wrote:
>> Why require the callee's author to add boilerplate? Just do it for all
>> ref params that are given an rvalue.
> 
> Because if the point of the function accepting its argument by ref is
> because it's going to mutate the argument, then it makes no sense for it to
> accept rvalues, 

1. That *isn't* always the core point of a function which takes a 
non-const ref argument.

2. It's the caller who decides whether or not the ref-result is needed, 
not the callee.

3. The frequent recurring complaints about no rvalue references are a 
testament that this is too common a use-case for the current "manually 
insert temporaries" workaround to be satisfactory.

4. If the whole point of disallowing rvalue references is to prevent 
accidents due to callers not realizing a param is being passed by ref 
(as it sounds like you're suggesting), then it's nothing but a broken 
half-solution, because it fails to provide that safety (and thus fails 
its own charter) when that same caller, once again not realizing a param 
is ref, passes an *lvalue* without expecting it to change. *If* the 
problem we want to solve here really is making sure a caller knows when 
a param is ref, we've failed, and the only way to actually accomplish it 
is the C# approach: Require callers to mark their ref args with "ref" 
and raise an error when they don't.