On 10 May 2013 09:09, Timon Gehr <timon.g...@gmx.ch> wrote:
> On 05/10/2013 12:42 AM, Manu wrote:
>
>> On 10 May 2013 08:09, Jonathan M Davis <jmdavisp...@gmx.com
>> <mailto:jmdavisp...@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-@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-@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?
