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

[Jonathan M Davis]

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). So, having ref in general accept rvalues would be a huge problem.
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.

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,
which has serious @safety implications, and in the case of C++, complicates
things considerably. Andrei has plenty of nasty things to say about how
rvalue references in C++ were a huge mistake. It's just that I can never
remember the arguments very well.

The use of scope with DIP 1000 may reduce the problem such that scope ref
could be made to work @safely (I don't know), but that by itself isn't
enough if you want it to be clear whether a function is supposed to be
mutating the argument or if it's just trying to avoid copying it. C++ solves
that problem by requiring const with rvalue references, but given how D's
const works, that really wouldn't make sense. So, we'd have to do something
else.

I get the impression that this issue is one where it seems like a small one
on the surface but that when you get into the guts of what it actually means
to implement it, it gets nasty.

I think that most of us have just take the approach of passing everything by
value unless the type is clearly too expensive to copy for that to make
sense, in which case, it's then passed by ref or auto ref, or we make it a
reference type. I don't know how much the problem with the lack of rvalue
references in D is a PR issue, because C++ programmers get annoyed about it
and deem D to be subpar as a result, and how much it's an actual performance
problem. I don't work in Manu's world, so I don't what really makes sense
there. For me, passing by value is usually a non-issue, and it's easy enough
to work around the problem in the rare cases where it is a problem. Clearly,
it's a PR issue in Manu's world, but it may also be a performance problem. I
don't know. Either way, it's clear that Manu and others like him think that
the fact that D doesn't have rvalue references is a serious deficiency.

- Jonathan M Davis