On 9 November 2012 21:39, 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, November 09, 2012 15:55:12 Manu wrote:<br>
> Does that actually make sense? Surely a function that receives a scope<br>
> argument can return that argument, since it's only passing it back to the<br>
> same function that already owns it... it knows it can trust that function,<br>
> since it was received from that function.<br>
<br>
</div>It can't. That would mean that the reference escaped. That would be<br>
particularly deadly for delegates. Think about what happens if the scoped<br>
delegate is put into a struct which is returned.<br>
<br>
struct Result<br>
{<br>
 delegate........ del;<br>
 ...........<br>
}<br>
<br>
Result foo(scope delegate....... bar)<br>
{<br>
 ..........<br>
 return Result(bar);<br>
}<br>
<br>
auto baz()<br>
{<br>
 Result r;<br>
 {<br>
 int n = 5;<br>
 r = foo((){writeln(n);});<br>
 }<br>
 r.del();<br>
}<br>
<br>
baz has no idea where the delegate in r came from. It has no idea that it<br>
wasn't allocated as a closure. So, it's not going to allocate one, which means<br>
that the delegate refers to a part of the stack which won't exist anymore when<br>
the delegate actually gets called. If scope wasn't used, that wouldn't have<br>
been a problem, because a closure would have been allocated as soon as the<br>
delegate had been passed to foo, but because scope was used, it knows that the<br>
delegate won't escape, so it doesn't allocate the closure (since it's not<br>
necessary). But that only works because scope prevents escaping - including by<br>
the return value. So, the above code _must_ be invalid.<br></blockquote><div><br></div><div>Okay, makes sense.</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">
>> Any struct holding any reference types would be<br>
> > in the same boat, as would any class or AA.<br>
><br>
> I don't follow the problem with reference args. surely they can be<br>
> evaluated just fine? Just that nothing can escape the function...<br>
<br>
</div>It's the fact that they can't escape the function which is the problem. If<br>
scope is working correctly, than any and all reference types which are passed<br>
to the function via a scope parameter (be it directly or within another<br>
object) cannot escape the function in any way shape or form. So, you can't<br>
assign any of them to any static or module-level variables (not generally a<br>
big deal) and you can't use any of them in the return value (often a big<br>
deal). Sometimes, that's exactly what you want, but in the general case, you<br>
don't want to prevent anything you pass into a function from being returned<br>
from it, so scope quickly becames overly restrictive.<br></blockquote><div><br></div><div>I'm still not buying this. Here's a common struct I will pass by ref (perhaps the most common struct in my industry):</div>
<div><br></div><div>struct Vector { float, x,y,z,w; }</div><div>struct Matrix { Vector xRow, yRow, zRow, wRow; }</div><div><br></div><div>Vector mul( scope const ref Matrix m, scope const Vector v)</div><div>{</div><div>  Vector v;</div>
<div>  // perform a matrix multiply against the vector...</div><div>  // this work uses every single field of the inputs given, but the result it produces has to references to the sources.</div><div>  // everything is operated on and copied to the output struct, which is returned.</div>
<div>  return result;</div><div>}</div><div><br></div><div>Why should this be a problem?</div><div>The majority of my work-horse structs apply to this pattern. This is what I imagine 'scope' to be for...</div><div>
The main advantage I expect is that I can have confidence that passing rvalues (temporaries) is safe, and that external code won't take references to memory that I may not own/control. Is that not the point?</div><div>
<br></div><div>Surely the problem that scope should be protecting against is a pointer to any part of the argument escaping. *Copies* of values contained in the argument/s are fine.</div></div></div>