Discussion: Rvalue refs and a Move construtor for D

[Atila Neves]

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.

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

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