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

[Jonathan M Davis]

On Friday, July 20, 2018 14:35:57 Manu via Digitalmars-d wrote:
> > > Their currently behaviour is mostly wrong, and the exact thing I'm
> > > trying to fix though.
> >
> > Why would the current behviour be mostly wrong? If the purpose of using
> > ref is to accept the current value of a variable and mutate it such
> > that the argument is mutated,
>
> That's not "the purpose of using ref".
> That is _one use_ of ref, and in my world, it's comparatively rare.

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.

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, while I sympathize with you about making it more user-friendly to pass
rvalues by ref in the case where you just want to avoid copies, I really
think that it merits its own attribute rather than messing up ref for what I
would have considered the common case.

- Jonathan M Davis