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

[Steven Schveighoffer]

On 7/20/18 1:16 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for 
> DIP 1016, "ref T accepts r-values":
> 
> https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md 
> 
> 
> All review-related feedback on and discussion of the DIP should occur in 
> this thread. The review period will end at 11:59 PM ET on August 3, or 
> when I make a post declaring it complete.
> 
> At the end of Round 1, if further review is deemed necessary, the DIP 
> will be scheduled for another round. Otherwise, it will be queued for 
> the Final Review and Formal Assessment by the language maintainers.
> 
> Please familiarize yourself with the documentation for the Community 
> Review before participating.
> 
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
> 
> Thanks in advance to all who participate.

Looks pretty good to me.

There is very little discussion of the original problem (the reason why 
ref does not bind to rvalues). I don't know if this will satisfy Walter.

A couple points to make there:

1. `this` has been binding as ref to rvalues since structs received 
`this` by ref (yes, they were pointers at one point), and there really 
have not been averse effects.

2. The case is made to allow return ref pipeline functionality, but does 
not address the other cases. A strawman to discuss is a function which 
takes a value-type by reference, and returns void. It's possible the 
function squirrels away a copy of the value somewhere, but unlikely (why 
would it take it by ref in that case?). I'd say 99% of the time the 
point is to modify the parameter for use after the function ends. But in 
the rvalue case, you will lose it immediately. So in effect a call that 
seemingly has some effect will have none.

I would point out that 1 here serves as an example of why 2 isn't 
critical -- you can easily get into this exact situation WITHOUT the DIP 
if the function in question is a member function. And people have 
stumbled across such issues, fixed the problems, and moved on. I would 
say from personal experience the occurrence of such bugs is pretty rare.

I would also point out that the issues with generic code that have been 
pointed out already apply here as well -- generic code might NOT CARE if 
the function has any effect, but having to do metacrobatics to call it 
the "right way" or avoid calling it on purpose would be painful to write 
(as has been demonstrated).

One further point, on the default arguments: you can have a default 
argument be ref, so make sure that section does not read like it 
*always* has to create a temporary.

-Steve