DIP 1016--ref T accepts r-values--Community Review Round 1

[Manu]

On Fri, 20 Jul 2018 at 22:45, Nicholas Wilson via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 21 July 2018 at 04:09:25 UTC, Jonathan M Davis wrote:
> > Honestly, I think we're just coming from points of view that
> > are too different. IMHO, the core use case for ref is for a
> > function to mutate an argument and have that result progagate
> > to the argument,
>
> I think the critical point here is that the the caller is free to
> ignore the refness of the arg by creating a temporary and not
> using it further.
>
> > and having ref accept rvalues is not only counter to that, but
> > it risks bugs that are currently impossible.
>
> A class of bugs I believe to be self-evident and incredibly
> sparse.
>
> >I think that having a way to accept rvalues by ref
> > for functions where you want to avoid copying is potentially
> > useful but not particularly critical. On the other hand, you
> > seem to see little or no value in having parameters that are
> > intended to only accept lvalues
>
> As the API author you can @disable the rvalue overload, but
> nothing you do can stop the caller supplying an unused temporary
> to the ref argument. Yes you can discourage them with
> docs/@disabled overload sets/ whatever, but you can't stop them.
> That is no different to today. This DIP may lessen your ability
> to discourage them from misusing it, but you can't stop a
> stubborn idiot, and that is not the audience D is targeting.
>
> > and see great value in having functions that accept rvalues by
> > ref in order to avoid copying.
>
> It is not just the avoiding copying, if it were I'm not sure I'd
> support it. For me the greatest benefit is the increase in
> readability due to not having useless temporaries everywhere in
> ref heavy code (that may not be under API user's control).

For me, the biggest win is reducing the amount of broken meta because
authors didn't think about ref up front (or ever).
Handling heaps of edge cases in complex meta really sucks; it's hard
to get right, and it's hard to test for. Most people NEVER test
anything with ref.
Removing unnecessary and awkward edge cases that result in brittle
code is always a good thing!

Also removing frustrating bloat and badly named temporaries (t, t1,
t2, etc) from places they never should have existed is a massive win.
Calling into C++, and via polymorphic interfaces also gain
disproportionate advantage.