<div dir="ltr">On 10 May 2013 08:09, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, May 10, 2013 07:35:36 Manu wrote:<br>
> I don't think this is entirely true, auto ref is a template concept, that<br>
> is, "automatic ref-ness", it selects the ref-ness of the argument<br>
> automatically, at compile time, just like auto applied everywhere else<br>
> (selects a type for instance, at compile time). This concept doesn't make<br>
> any sense applied to a non-template. It *IS* a ref as specified by the<br>
> programmer, there's nothing 'automatic' about it.<br>
<br>
</div>I don't buy this at all. The entire point of auto ref on parameters was to say<br>
that you wanted to accept both rvalues and lvalues efficiently. The fact that<br>
the template implementation happened to forward refness as a result was a<br>
happy accident.</blockquote><div><br></div><div style>Or perhaps it's actually the core promise that was just poorly understood at the time?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
auto ref is already described in TDPL, and it has nothing to<br>
do with templates there. Using auto ref on non-templated functions would be<br>
completely in line with what TDPL describes and would implement another<br>
feature from TDPL that we're currently missing.<br></blockquote><div><br></div><div style>Making it blindly suit the book, whether that idea was initially right or wrong without having actually tried it out or argued it through is not a compelling argument for my money.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> This is the reasoning for the argument behind scope ref, which to my mind<br>
> actually makes good sound sense, and should lead people to a proper<br>
> understanding of what you are actually doing.<br>
<br>
</div>The whole point of making auto ref work with non-templated functions is to be<br>
able to say that you want to pass both rvalues and lvalues by ref so that they<br>
get passed efficiently.</blockquote><div><br></div><div style>Efficiency can not be implied by ref-ness. There are lots of factors, and the programmer needs control over which is chosen.</div><div style>auto ref would seem to me as something of a hack that is required when dealing with ref and templates, because ref is not part of the type like C++.</div>
<div style>auto ref on templates wouldn't exist if ref was part of the type, it would infer ref-ness automatically like C++ does. Even Walter agreed that it felt like a hack for this reason during conversations.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">scope says _nothing_ about that. It's all about what<br>
escapes the scope, not about how stuff gets passed.</blockquote><div><br></div><div style>It says it in a more pure way. The point is that it is made explicit that the argument will not escape the scope it is given, thus, in conjunction with ref, it becomes naturally safe to pass r-values.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, using scope ref to<br>
solve that problem makes no sense, and the changes that we've proposed to make<br>
to ref to make it @safe pretty much make scope unnecessary.</blockquote><div><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> scope ref would be<br>
virtually identical to ref given that ref already has to guarantee that the<br>
variable being referenced doesn't get destroyed before the ref is.</blockquote><div><br></div><div style>No, there are other bonuses:</div><div style> - It mechanically enforces a given argument will not have a pointer taken and escape.</div>
<div style> - It gives the extra information to the programmer who can better reason about API intent.</div><div style> - It allows 'ref' alone to retain an important function where it may escape a pointer if it wants to.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only<br>
real difference would be that scope would presumably additionally prevent doing<br>
@system stuff like taking the address of the ref. I don't see how this buys us<br>
anything.<br></blockquote><div><br></div><div style>Yes this is an advantage, I listed it above. It buys the programmer some additional flexibility/choice.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I agree that auto ref isn't a great name, but it's what we already have, and<br>
using it on non-templated functions would be using it for exactly what it was<br>
designed for in the first place and how it's described in TDPL.</blockquote><div><br></div><div style>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.</div>
<div style>auto ref has already shown to create misunderstanding in the minds of non-super-technical programmers. Syntax should encourage correct understanding.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 The only reason<br>
that it's not what we have now is because Walter misunderstood it when he<br>
implemented it.<br></blockquote><div><br></div><div style>If that's true, I'm glad he did. Or perhaps he never agreed to it in the first place.</div><div style>His misunderstanding suggests that he never actually agreed to the initial proposal that you refer to.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Considering the key argument against 'scope ref' is that people don't want<br>
> to require more attributes to make use of it, I don't see how 'auto ref'<br>
> satisfies this argument either.<br>
<br>
</div>Because we already have auto ref. It just hasn't been implemented on non-<br>
templated functions yet even though it was supposed to be.</blockquote><div><br></div><div style>...so, we don't have it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And you were<br>
proposing not only using scope ref with a particular meaning on function<br>
parameters but also adding it as a return type, which it definitely isn't know<br>
regardless of what scope of function parameters does or doesn't do.</blockquote><div><br></div><div style>I'm (note: not originally my proposal, although I shared the thought) proposing that scope has a uniform meaning as applied to any variable anywhere, where it's a local, or an argument (just a local declared in a different spot), or a return value (yet another local, declared in a different spot), the meaning is consistent.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And it's<br>
even questionable that scope as originally intended can be properly<br>
implemented anyway.<br></blockquote><div><br></div><div style>...so, the problem is no different than 'auto ref' as you mention above. It's not implemented as drafted, and we're debating what's actually correct. Clearly the draft was incomplete in both cases.</div>
<div style>I only support the proposal (from others) that scope ref makes so much more sense, and I think we've also proven it can be made to work syntactically without holes, which I don't believe is so for auto ref.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Thus, I am quite happy happy with 'ref', it can be made safe, satisfies the<br>
> argument above, and this seems like a very good start that we might<br>
> actually all agree on.<br>
<br>
</div>As has already been discussed in this thread, it will introduce maintenance<br>
problems if ref accepts rvalues.<br></blockquote><div><br></div><div style>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.</div>
</div></div></div>