Discussion: Rvalue refs and a Move construtor for D

Manu turkeyman at gmail.com
Tue Sep 3 17:04:25 UTC 2019


On Tue, Sep 3, 2019 at 7:40 AM Atila Neves via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Thursday, 29 August 2019 at 19:04:45 UTC, Manu wrote:
> > 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:
> >> >> [...]
> >> >
> >> > 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.
>
> I've opened it before. I don't know how much of it is accidental
> complexity. The last time, I assumed none of it was.

You have to look no further than a call to `memcpy` in any of those
functions to know it's all terrible.

> > 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.
>
> So you've mentioned before. It'd be really helpful to have a list
> of those bugs and edge cases.

I fix them as soon as finding them, but that still doesn't help that
it's a mad and terrible hack, it's just one that gets closer to
working.

> > 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.
>
> The C++ implementation is simple because the language is not by
> having rvalue references.

I don't think that's the case. Evidently, C++'s solution is a lot
simpler than our solution, language included. I mean, we can't move at
all.
'Simple' is only better if it actually works. If it's simple and
doesn't work, then it's not better (see, copy-ctor replacing postblit
for example).


More information about the Digitalmars-d mailing list