<div dir="ltr">On 10 May 2013 09:01, Rob T <span dir="ltr"><<a href="mailto:alanb@ucora.com" target="_blank">alanb@ucora.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Thursday, 9 May 2013 at 21:55:51 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Umm, what if the non-template counterpart returns ref? Then it doesn't<br>
behave the same.<br>
</blockquote>
<br></div>
Yes, the non-template version cannot ref return an auto ref param, but I would expect that neither can the template version unless auto ref is specified as the return value. The key difference that I think can be understood is that auto ref on the return value for a template is not the same thing as auto ref on the param.<br>

<br>
For templates, you can enforce exactly the same behavior as the non-template version by specifying a return of either ref or not, ie you do not specify auto ref or you specify a return by value.<br>
<br>
If you so happen to specify a ref return of an auto ref param, I would expect the compiler to refuse to compile no matter if it is a template function or not. Of course you can confuse the programmer and allow such a thing to compile only for the cases where it can return ref on the auto ref, but IMO that'll be a big mistake as it will confuse the s*** out of most people, and besides allowing something like that has no value at all.<br>

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
D is a complex language, so stuff like this does take some getting used to,<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
but it is very powerful and flexible, no two ways around it.<br>
<br>
</blockquote>
<br></div><div class="im">
If this takes 'getting used to', you're basically admitting that it doesn't<br>
make intuitive sense.<br>
</div></blockquote>
<br>
Well, I suppose I cannot disagree with you on that point, so yes it is confusing, but for sake of a solution, it is not nearly as confusing so long as auto ref on the parameters will behave the same for both template and non-template versions in a consistent way. I know auto ref on the return is potentially confusing, but it does increase template flexibility as the benefit.<br>
</blockquote><div><br></div><div style>It IS confusing that auto-ref would do 2 completely different things. One automatically selecting ref-ness, the other saying "i can safely receive a temporary". There is nothing 'automatic' about the latter.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Alternatively, I think Jonathan's argument against scope ref makes perfect sense. Unless I misread something or he's dead wrong, how can scope be used without creating even more confusion? Even if scope has some properties in common with auto ref, it specifies something entirely different than accepting rvalues and lvalues. This point reminds me of why we should not be using bool as an integral type, it's the same reasoning.</blockquote>
<div><br></div><div style>Which argument?</div><div style><br></div><div style>Correct, it specifies something _entirely different_, it says "I can safely receive a temporary, because I promise not to escape it". This is the actual problem that we're trying to solve, and it addresses the problem head on.</div>
<div style><br></div><div style>As I've had to re-iterate countless times, and such is the massive fallacy behind all of these threads, this whole debate is NOT about lvalues/rvalues, and I wish people would stop using the term 'rvalue' in their posts, I worry that they misunderstand the problem every time it's said.</div>
<div style><br></div><div style>This code is broken:</div><div style>  void f(ref int x) {}</div><div style>  int x;<br></div><div style>  f(x);</div><div style><br></div><div>x is an lvalue.</div><div>This is the real problem case, and addressing this will solve the rvalue case at the same time.</div>
<div style>Passing an rvalue to a function just generates an implicit temp which is functionally identical to the above, except the lifetime of a temp is usually the life of the statement rather than the outer scope.</div>
<div style>The problem we need to solve is that of a function being able to safely receive a _temporary_.</div></div></div></div>