The liabilities of binding rvalues to ref

[Manu]

On 10 May 2013 09:09, Timon Gehr <timon.gehr at gmx.ch> wrote:

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


Fine. @safe is expected to place more restrictions. But it's still
something that people need to do sometimes in un- at safe code.

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


The fact that it can safely receive a temporary is implicit if there is a
guarantee that it will not escape.

Why should explicit syntax exist to say "I accept rvalues", and not "I can
safely receive temporaries"? The rvalue case is a subset, and I see no
reason for it to receive special treatment.

   - It allows 'ref' alone to retain an important function where it may
>> escape a pointer if it wants to.
>>
>>
> In @safe code? No way.
>

Sure, people expect restrictions in @safe code. But it's still something
that people need to do sometimes in un- at safe code.

     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.


What?

 Syntax should encourage correct understanding.
>>
>>
> It can't. FWIW overloading scope fails this requirement badly.
>

It's not an overload, it's a natural extension of the concept.
Using auto is an overload!

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

I don't understand? Can you expand this comment?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130510/94bd8e4e/attachment.html>