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

[Manu]

On 23 March 2018 at 16:46, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> 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).

Okay, let's read 'const ref' every time I say 'ref'. I thought that
would be fairly safe to assume. Sorry!


> 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.

No, no attributes.. Just accept any argument to const-ref!
The function's not gonna change it.


> 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)

True, but if you follow that line of reasoning, then this case must
equally be banned:

T temp = f();
func(temp);

The @safety fear is that the pointer to the stack arg may escape, and
that's identical whether the argument is an explicit temp, or an
implicit one.


> but that by itself isn't
> enough if you want it to be clear whether a function is supposed to be
> mutating the argument

Functions that receive const args make it pretty clear that they don't
intend to mutate the arg.


> 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.

It really doesn't... the compiler just make the same temp that I type
with my hands. That's literally all that it needs to do. I'd bet money
it's a one-paragraph change.


> 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.

That's an understatement, but yes :P
We want to call C++ code. The D code shouldn't be objectively worse
than the C++ code we're trying to escape, otherwise we're undermining
our gravity towards D.
We can't have a situation that goes "I wrote this 3 line function in
D, but now it's 6 lines because I had to break args to temps, it's
objectively worse than the equivalent C++ function... why am I writing
it in D again?".