The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/10/2013 12:42 AM, Manu wrote:
> On 10 May 2013 08:09, Jonathan M Davis <jmdavisProg at gmx.com
> <mailto:jmdavisProg at gmx.com>> wrote:
> ...
>     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.
>
>
> I agree, that's why I'm also happy with 'ref' alone, but I still feel it
> doesn't communicate as much information, which is a trivial by contrast.
>
>     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.
>
>
> No, there are other bonuses:
>   - It mechanically enforces a given argument will not have a pointer
> taken and escape.

This is the same for 'ref' in @safe code in the final implementation.

>   - It gives the extra information to the programmer who can better
> reason about API intent.

No. scope is supposed to restrict escaping (in some way that is still to 
be determined). If it is overloaded to also mean 'accept rvalues', then 
reasoning about API intent is actually harmed, because it will not clear 
whether 'scope' was added to restrict escaping alone or also to accept 
rvalues.


>   - It allows 'ref' alone to retain an important function where it may
> escape a pointer if it wants to.
>

In @safe code? No way.

>     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.
>
>
> Yes this is an advantage, I listed it above. It buys the programmer some
> additional flexibility/choice.
>
>     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.
>
>
> I'm not going to change my position that it makes no sense, and is
> misleading/confusing without some real arguments, which nobody seems
> able to provide.
> auto ref has already shown to create misunderstanding in the minds of
> non-super-technical programmers.

I think that this should be an oxymoron.

> Syntax should encourage correct understanding.
>

It can't. FWIW overloading scope fails this requirement badly.


> ...
>
>     As has already been discussed in this thread, it will introduce
>     maintenance
>     problems if ref accepts rvalues.
>
>
> I'm not bothered by that personally, but if it's critically important,
> then we start arguing scope ref again. Otherwise I am happy to accept
> 'ref' with new added safety.

Either scope ref will turn out to be liable to similar issues, or a 
keyword will have been wasted.