The liabilities of binding rvalues to ref

[Jonathan M Davis]

On Friday, May 10, 2013 07:35:36 Manu wrote:
> I don't think this is entirely true, auto ref is a template concept, that
> is, "automatic ref-ness", it selects the ref-ness of the argument
> automatically, at compile time, just like auto applied everywhere else
> (selects a type for instance, at compile time). This concept doesn't make
> any sense applied to a non-template. It *IS* a ref as specified by the
> programmer, there's nothing 'automatic' about it.

I don't buy this at all. The entire point of auto ref on parameters was to say 
that you wanted to accept both rvalues and lvalues efficiently. The fact that 
the template implementation happened to forward refness as a result was a 
happy accident. auto ref is already described in TDPL, and it has nothing to 
do with templates there. Using auto ref on non-templated functions would be 
completely in line with what TDPL describes and would implement another 
feature from TDPL that we're currently missing.

> This is the reasoning for the argument behind scope ref, which to my mind
> actually makes good sound sense, and should lead people to a proper
> understanding of what you are actually doing.

The whole point of making auto ref work with non-templated functions is to be 
able to say that you want to pass both rvalues and lvalues by ref so that they 
get passed efficiently. scope says _nothing_ about that. It's all about what 
escapes the scope, not about how stuff gets passed. So, using scope ref to 
solve that problem makes no sense, and the changes that we've proposed to make 
to ref to make it @safe pretty much make scope unnecessary. scope ref would be 
virtually identical to ref given that ref already has to guarantee that the 
variable being referenced doesn't get destroyed before the ref is. The only 
real difference would be that scope would presumably additionally prevent doing 
@system stuff like taking the address of the ref. I don't see how this buys us 
anything.

I agree that auto ref isn't a great name, but it's what we already have, and 
using it on non-templated functions would be using it for exactly what it was 
designed for in the first place and how it's described in TDPL. The only reason 
that it's not what we have now is because Walter misunderstood it when he 
implemented it.

> Considering the key argument against 'scope ref' is that people don't want
> to require more attributes to make use of it, I don't see how 'auto ref'
> satisfies this argument either.

Because we already have auto ref. It just hasn't been implemented on non-
templated functions yet even though it was supposed to be. And you were 
proposing not only using scope ref with a particular meaning on function 
parameters but also adding it as a return type, which it definitely isn't know 
regardless of what scope of function parameters does or doesn't do. And it's 
even questionable that scope as originally intended can be properly 
implemented anyway.

> Thus, I am quite happy happy with 'ref', it can be made safe, satisfies the
> argument above, and this seems like a very good start that we might
> actually all agree on.

As has already been discussed in this thread, it will introduce maintenance 
problems if ref accepts rvalues.

- Jonathan M Davis