Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Sat, Sep 7, 2019 at 2:45 PM kinke via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 7 September 2019 at 21:09:45 UTC, Suleyman wrote:
> > On Saturday, 7 September 2019 at 12:04:49 UTC, kinke wrote:
> >> ```
> >> void foo()(auto ref S s)
> >>   if (__traits(isRvalueRef, s));
> >> ```
> >
> > This is a really just an awkward way of doing `void foo(@rvalue
> > ref S s)`.
> >
> >> I'd prefer the latter value-view, as that's compatible with
> >> current semantics.
> >
> > At this point you have essentially admitted rvalue ref in the
> > language but you're fighting to keep it hidden from the user as
> > much as possible.
>
> Yes.
>
> > I personally don't thing rvalue ref is that much dangerous to
> > be kept away from the programmers hand. Hiding rvalue ref under
> > auto ref is simply discouraging people from using it.
>
> It's not because of dangerousness or such, but firstly because I
> think pure rvalue refs (disallowing lvalue args) are used
> extremely seldomly, and secondly because I want to avoid further
> syntactic complexity. We have ref, auto ref, scope ref, return
> ref, now we're discussing @rvalue ref...

My experience with D has shown me time and time again, when something
exists in the language that has no actual language to interact with
it, that is the *real* complexity in D.
Everything that sucks the most in D is the things that have no proper
expression in the language.
D is a power-user language, and that ship sailed a very long time ago.
We still have D's current default move semantics, and they will not
disappear; your average user will not be affected by this. For the
power user that needs it though, direct expression is *MUCH* simpler
than making them jump through hoops to interact with a language
feature indirectly.
We've done that a lot before, and it's a disaster every single time.