Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Thu, Aug 29, 2019 at 2:45 AM Atila Neves via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Thursday, 29 August 2019 at 04:38:03 UTC, Manu wrote:
> > On Wed, Aug 28, 2019 at 8:45 PM Suleyman via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On Thursday, 29 August 2019 at 01:01:36 UTC, Mike Franklin
> >> wrote:
> >> > [...]
> >>
> >> I discussed this with Manu which is pro rvalue ref and he made
> >> a lot of good points, the most important thing is that rvalue
> >> ref would drastically simplify the implementation of
> >> `core.lifetime.move()`.
> >>
> >> But he pointed out that auto ref already does perfect
> >> forwarding.
> >
> > It's a _part_ of perfect forwarding; the part that allows a
> > function
> > to receive forwarded arguments.
> > The other part is a `forward` implementation passes them
> > forward (and
> > actually works), and that depends on a `move` implementation
> > that
> > works.
>
> What's wrong with the current `move` and `forward`
> implementations?

Open core.lifetime and look at the text. If you're not terrified, then
you're a braver man than me.
Then also consider that the file has edge cases and bugs which I've
run into on numerous occasions. We don't have move semantics, we have
copy-elision and a bunch of hacks that unnecessarily call memcpy a lot
of times (and don't actually work).
Our move semantics are slow (lots of copying, not actually moving),
and occasionally broken.

For reference, here's the C++ implementation of that entire file:

template <class T>
T&& move(T& val) { return (T&&)val; }

Our implementation would/should be similar.