<div dir="ltr">On 10 April 2013 15:30, kenji hara <span dir="ltr"><<a href="mailto:k.hara.pg@gmail.com" target="_blank">k.hara.pg@gmail.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">2013/4/10 Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why are you suggesting changing scope to imply ref? This seems wrong. scope and ref are separate, should remain that way.</div>
<div></div></div></div></div></blockquote><div><br></div></div><div>I say that 'scope' itself should not imply 'ref'. It is *possible* but would break existing code meaning, so it should not be applied.</div>
</div></div></div></blockquote><div><br></div><div style>Right. Absolutely agree then! :)</div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div>Arguments would be scope ref, or in ref, thus allowing rvalues. Without ref, I would imagine that the meaning is such that, even though the argument is a copy, it, or members thereof are not allowed to escape.</div>


<div><br></div><div>struct X { int *p; }</div><div>int* global;<br></div><div><br></div><div>void func(scope X x) // note: is not ref</div><div>{</div><div>  global = x.p; // <- error! scope prevents any part of x escaping, even though it's a copy.<br>


</div><div>}</div><div><br></div><div>This way, scope has meaning with or without ref.</div></div></div></div></blockquote><div><br></div></div><div>That is an enhancement. Similar things is now in my mind, but it is not yet output.</div>
</div></div></div></blockquote><div><br></div><div style>I think this is a tool that will greatly enhance working with @safe in the future. I look forward to it.</div><div style><span style="color:rgb(80,0,80)"><br></span></div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">And, 'scope' is alredy used for delegate parameter.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">int opApply(scope int delegate(ref int) dg);</div><div class="gmail_extra"><br></div><div class="gmail_extra">Such a semantic modification will silently change the meaning of existing code. It's not good to me.</div>


</div></div></blockquote><div><br></div></div><div>What does scope mean in this case? Is this a conflict in some way?</div></div></div></div>
</blockquote></div></div><br></div><div class="gmail_extra">Compiler guarantees that given delegate to the scope parameter never make a closure.</div><div class="gmail_extra">It would avoid heap allocation.</div></div></blockquote>
<div><br></div><div style>Do you have any ideas/solutions that still fit this proposal?</div><div style>I tend to think the value of this proposal is of extreme significance to D. It is, without doubt, the single biggest complaint I've heard by virtually every programmer I've introduced D to, and the future implications for @safe improvements are valuable too.</div>
</div></div></div>