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

[Manu]

On 26 March 2018 at 17:30, Rubn via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote:
>>
>> C++ T&& (Rvalue reference) -> D T
>
>
> Not really, in C++ it is an actual reference and you get to choose which
> function actually does the move. In D it just does the copy when passed to
> the function. So you can't do this in D.
>
> void bar(T&& t)
> {
>     // actually move contents of T
> }
>
> void foo(T&& t)
> {
>     bar(std::forward<T>(t)); // Can't do this in D without making another
> actual copy cause it isn't a reference
> }

You can still get there with D, if you assume the forwarding function
is simple enough to inline (and the code is public).
I was cautiously concerned about this for a long time, but I've never
made a noise about it. I've digested and resolved that's okay though
:)
There are very few cases where you will fail to achieve equivalent
efficiency, and I think D's amazingly simplified move semantics more
than compensate for any conceivable loss.


>> If replacing const T& with T chafes, I understand. I used to feel that way
>> too. It's _possible_ that would incur a penalty in copying/moving, but IME
>> the cost is either 0, negligible, or negative (!).
>>
>> As mentioned above, if calling C++ code there's no choice about using T
>> instead of const T&, so for pragmatic reasons that should be allowed. But
>> only there, because...
>>
>>> Can you please explain these 'weirdities'?
>>> What are said "major unintended consequences"?
>>
>>
>> Rvalue references. They exist because of being able to bind temporaries to
>> const T& in C++, which means there's no way of knowing if your const T& was
>> originally a temporary or not. To disambiguate C++11 introduced the type
>> system horror that are rvalue references (which also do double-duty in
>> enabling perfect forwarding!).
>
>
> What's a concrete example that you would be required to know whether a
> const& is a temporary or not. I don't really see it otherwise. The solution
> everyone is saying to use as an alternative would be the literal case of how
> it would be implemented in the language.

He's trying to say that C++ introduced rvalue references because
normal references weren't able to allow for move semantics to exist.
It's a red-herring. D already has move semantics, they work well, and
they're not on trial here.

In C++'s case, it's not that references were deficient at being
references that C++ needed rval-references, it's that references were
deficient at being move-able.
That is not a problem that exists in D. It's fine for references to
just be references in D. We're not struggling to make references
move-able in D, that's not a thing, we already have move semantics.
Any extension of this conversation about references into C++
rvalue-references (T&&) and or move-semantics are red-herrings.
There's no such problem in D that needs to be resolved, and the
existing solution is excellent.