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