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

[Nick Sabalausky (Abscissa)]

On 03/23/2018 07:46 PM, Jonathan M Davis wrote:
> On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote:
>> It never made any sense to me that there could be any problem
>> with the compiler automatically creating a temporary hidden
>> lvalue so a ref could be taken. If there IS any problem, I can
>> only imagine it would be symptomatic of a different, larger
>> problem.
> 
> It can be a serious API problem if you can't look at ref and know that the
> intention is that the original argument's value will be used and then
> mutated (whereas with out, it will be mutated, but the original value won't
> be used).

???. That's equally true when an lvalue is passed in.

> However, that could be solved by having a different attribute indicate that
> the idea is that the compiler will accept rvalues and create temporaries for
> them if they're passed instead of an lvalue. Then, the situation is clear.

Why require the callee's author to add boilerplate? Just do it for all 
ref params that are given an rvalue.

> As for rvalue references in general, I can never remember what exactly the
> problem is. IIRC, part of it relates to the fact that it makes it impossible
> for the compiler to know whether it's dealing with an actual lvalue or not,

As long as the compiler takes the advocated "automatic hidden temporary" 
approach, then it *is* an actual lvalue. We're talking nothing more than 
sugar here. Sugar for what we're already forced to do manually. There 
*cannot* be a technical problem here that isn't *already* a problem with 
the author manually creating a temp var.