rvalues -> ref (yup... again!)

[Jonathan M Davis]

On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote:
> On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d
>
> <digitalmars-d at puremagic.com> wrote:
> > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky  via Digitalmars-d
> >
> > wrote:
> >> On 03/23/2018 09:06 PM, Jonathan M Davis wrote:
> >> > My biggest concern in all of this is that I don't want to see ref
> >> > start
> >> > accepting rvalues as has been occasionally discussed. It needs to be
> >> > clear when a function is accept an argument by ref because it's going
> >> > to mutate the object and when it's accepting by ref because it wants
> >> > to
> >> > avoid a copy.
> >>
> >> That ship sailed ages ago: It's already unclear. If we want to fix
> >> that,
> >> we can fix it, but blocking rvalue ref does nothing for that cause.
> >
> > Really? And how often does ref get used just to avoid copying? You can
> > almost always look at a function, see that it accepts ref, and know that
> > it's supposed to mutate the argument. Functions that want to avoid
> > copying lvalues usually use auto ref, not ref, whereas if ref accepted
> > rvalues, a number of folks would start using it all over the place to
> > avoid copying. Right now, folks rarely use ref that way, because it
> > becomes too annoying to call the function with an rvalue. So, while it
> > might not be the case 100% of the time right now that ref is used with
> > the purpose of mutating the argument, it almost always is. As such, you
> > can pretty reliably look at a function signature and expect that if one
> > of its parameters is ref, it's going to be mutating that argument. The
> > function that accepts an argument by ref with no intention of mutating
> > it is very much the exception, and I really don't want to see that
> > change.
>
> Interesting. Just understand that you're trading that feeling for a
> suite of edge cases though. Accepting asymmetric calling rules is a
> pretty big cost to pay for that 'nice thought'.
> That idea also dismisses the existence of the set of cases where ref
> is genuinely useful/correct. Your sentiment effectively puts those use
> cases into the position of 2nd-class citizens.
> I understand your sentiment, but I think the cost is not balanced, or
> even particularly fair with respect to users in those niche groups :/

I'm not arguing against having a way to indicate that a parameter accepts
both rvalues and lvalues and that the rvalues get copied to an invisible
variable so that they can be passed as an lvalue. I'm arguing against simply
making ref have that behavior. Assuming that the details of how that worked
internally didn't involve problematic stuff like the rvalue reference stuff
that Andrei and Walter are so against, having an attribute such as @rvalue
to attach to a ref parameter to allow it to accept rvalues would be fine
with me. I just don't want ref by itself to lose its current semantics,
because that would dilute its meaning and increase its amiguity.

I want to be able to look at a function signature, see ref without other
qualifiers, and be reasonably certain that the function is supposed to be
mutating that argument, whereas if ref by itself accepted rvalues, then we
lose that. If an attribute were used to make it allow rvalues, then we
wouldn't.

- Jonathan M Davis