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

[Manu]

On Fri, 20 Jul 2018 at 06:21, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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).

I sincerely hope you're in the minority :(

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

That is *one use* for ref. I produced text to the effect of changing
your mental model and such assertions.

"This DIP proposes that we reconsider the choice to receive an
argument by value or by reference as a detail that the API *author*
selects with respect to criteria relevant to their project or domain."

Could I improve communication of that sentiment?

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

Absolutely. 'ref' is arbitrarily suppressed in today's language.

> and that's not only error-prone, but it obfuscates what ref
> was originally intended for.

Ref's original 'intent' was narrower than it's practical use. We're
specifically trying to relax the restrictions to respect that reality.

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

If the function uses ref to return results, many such cases use can 'out'.
Functions that mutate the argument to return results aren't
automatically a dismissal of results; perhaps the function is impure,
or it receives multiple args (and one is uninteresting).
It is legitimate to discard the outputs of any function, whether you
ignore the functions return value OR whether you ignore results output
via ref.
Ignoring the return value raises the same argument, but you don't have
this reaction in that case.

It's too strict to frustrate all other useful applications of ref
because of a strict application of this arbitrary rule.

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

This DIP proposes how to retain your desired
passing-rvalue-is-an-error feature, and also demonstrates the
symmetrical mechanism for lvalues too.