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

[Nicholas Wilson]

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