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

[Jonathan M Davis]

On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d 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/725541d69149bc85a9492f7df07360f8e2948bd
> 7/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.

I am completely against allowing ref to accept rvalues without some sort of
attribute indicating that it should be allowed to (e.g. @rvalue ref).
Allowing ref to accept rvalues goes completely against the idea that ref is
for passing an object so that it can be mutated and have its result affect
the caller. With this DIP, we'd likely start seeing folks using ref all over
the place even when it has nothing to do with having the function mutating
its arguments, and that's not only error-prone, but it obfuscates what ref
was originally intended for.

auto ref was already introduced to solve this problem. The problem of course
is that it requires that the function be templated, and while that's often
desirable, it's not always a viable option (e.g. it doesn't work with
virtual functions). So, I'm fine with adding something akin to auto ref
which is intended to solve the non-templated case with semantics similar to
those described in the DIP, but I think that it would be a huge mistake to
make normal ref accept rvalues.

IMHO, having it be an error to pass an rvalue by ref is often a very
valuable behavior, and I do _not_ want to lose that. I would be fine if this
DIP proposed an attribute such as @rvalue to enable ref to accept rvalues,
but I very much hope that this DIP is not accepted so long as it allows ref
to accept rvalues without such an attribute.

- Jonathan M Davis