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.
