<div dir="ltr">On 27 April 2013 13:29, Diggory <span dir="ltr"><<a href="mailto:diggsey@googlemail.com" target="_blank">diggsey@googlemail.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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't see myself ever getting on board with this auto-ref idea. I just<br>
think it's crazy. It makes no sense to me, they are completely unrelated<br>
concepts. It will only lead to confusion.<br>
<br>
I'm back at scope-ref. Kenji is right as far as I'm concerned. Not to<br>
mention, he actually did the work.<br>
It makes perfect sense, and I can't see any reason why auto-ref should be<br>
used instead of something that actually makes intuitive sense, and people<br>
will eventually want to use anyway...<br>
</blockquote>
<br></div>
I'm against "scope ref" as the one thing "scope" means is that the parameter cannot be returned, and preventing rvalue references being returned breaks the one thing they are useful for.<br></blockquote>
<div><br></div><div style>It would have to return 'scope ref' also. This returns ownership to the calling statement, which is fine, because it is where the temporary originated in the first place.</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">
The primary use of rvalue references in C++ is so that these three cases work:<br>
vector<T> vec;<br>
T t;<br>
vec.push_back(T()) // Move semantics (temporary is destroyed in the process)<br>
vec.push_back(t) // Copy semantics ('t' is unmodified)<br>
vec.push_back(move(t)) // Move semantics ('t' is destroyed in the process)<br>
<br>
This allows best efficiency (move is at least as fast as copy, so when the original is no longer needed a move should be performed)<br>
<br>
The way it works is that push_back() has two overloads:<br>
push_back(T&& v) {<br>
    // Move 'v' into the vector, afterwards 'v' will have had its guts ripped out so to speak...<br>
}<br>
push_back(const T& v) {<br>
    // Copy 'v' into the vector, 'v' is unmodified<br>
}<br>
<br>
- r-values such as 'T()' will default to the first overload.<br>
- l-values such as 't' will default to the second overload.<br>
- 'move(t)' returns an r-value causing the first overload to be called.<br>
<br>
As you can see, using "scope ref" will break this third case because 'move()' won't be able to return an r-value, and if only the first two cases are going to be possible, this can be done without any special notion of r-value references anyway.<br>

<br>
I'm starting to think there does need to be new syntax if all three of the above cases are to be covered - it would work just making "ref" accept rvalues but then "move" would be the default for lvalues, and that would be confusing - but I don't think using "scope" solves any problems, as the semantics required for rvalues are orthogonal to what "scope" actually means.<br>

<br>
As good as it is to avoid adding new keywords, I think this might be a case where it's warranted...<br></blockquote><div><br></div><div style>scope ref T func(scope ref T t) { return t; }<br></div></div></div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>I think this solves the problem.<br></div></div>