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

[Manu]

On Fri, 20 Jul 2018 at 05:40, Steven Schveighoffer via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

I'm not aware of any substantial discussion?
I understand the design is to prevent accidental disposal of function results.

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

Interesting. I'm not sure how to write this in a sentence, can you
produce a patch or PR?

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

Do you really think words on this are valuable? It's already a very long DIP.
There is comment that the original design was intended to prevent
accidental loss of function results, and the rest of the DIP tries to
establish that that decision is out of date.
I think the discussion you are asking for is there... perhaps you can
suggest how you'd be satisfied here?

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

I understand your points. I'm not sure I have a sense of the text
you'd like to read though.
If you'd like to suggest a specific patch, or PR, that'd be get me on
the same wavelength :)

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

Got it.