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

[Nicholas Wilson]

On Friday, 20 July 2018 at 23:35:46 UTC, Jonathan M Davis wrote:
> On Friday, July 20, 2018 14:35:57 Manu via Digitalmars-d wrote:
> Comparatively rare? It's exactly what most functions using 
> output ranges need to do. For many output ranges, if the 
> function copies the range instead of copying, then you have a 
> serious bug, because then the data that gets put to the output 
> range inside the function does not affect the function argument 
> - or worse, if it's a pseudo-reference type, it can partially 
> mutate the argument, putting it in an invalid state. So, unless 
> a function that accepts an output range is supposed to be 
> taking ownership of it, the function needs to mark the output 
> range parameter with ref, and it would be a bug for it to 
> accept an rvalue.
>
> If anyone screws up and does something like return an output 
> range from a function without that function returning ref and 
> then passes it to a function that is intended to operate on an 
> output range, they would currently get an error, whereas with 
> this DIP, they would instead get subtle bugs with their 
> severity depending on what type of ouput range it was and what 
> the code was doing with it.

This is an interesting case not completely covered by Manu's 
prior reasoning (that you can't muck it up because you need to 
use it after e.g. appender). But for the case that you would not 
need it later either you already have it as a lvalue (e.g. from a 
function parameter) or its some kind of singleton (e.g. nullSink 
or put's to a global variable).

> And yes, in most cases, programmers would not pass something 
> other than a variable to a function that is clearly designed to 
> take its argument by ref and mutate it, but with the heavy use 
> of properties in a lot of D code, it can be trivial to operate 
> on something that looks like an lvalue but isn't. Right now, 
> such code gets caught, because it's an error to pass an rvalue 
> to a ref parameter, but with this DIP, that would no longer be 
> true. The situation gets even worse when you consider code 
> maintenance issues like when someone initially has something be 
> a variable and then later changes it to a property function and 
> doesn't make it return by ref (and property functions usually 
> don't return by ref). With this DIP, there could easily be 
> silent code breakage as a result, whereas such breakage would 
> not be silent with the current semantics for ref.
>
> Honestly, I don't see how accepting rvalues by ref is anything 
> but error-prone for any case where the ref is there because the 
> argument is supposed to be mutated and then be used after the 
> function call. And while you may very well want to use ref 
> simply to avoid copying - and may do that frequently right now 
> in spite of that being a pain with rvalues - I have exactly the 
> opposite experience that you seem to with regards to how ref is 
> used. In my experience, using ref to avoid copies is rare, and 
> using it to have the argument be mutated is what's common.

So this problem is restricted output range @properties that 
somehow don't return by ref, aren't intended to be used after 
having data written to them _and_ aren't singleton like?