<div dir="ltr">On 10 April 2013 12:40, 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><div class="h5"><div class="gmail_extra"><div class="gmail_quote">2013/4/10 Zach the Mystic <span dir="ltr"><<a href="mailto:reachzach@gggggmail.com" target="_blank">reachzach@gggggmail.com</a>></span><br>
<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">
On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:<br>
<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">
<a href="http://wiki.dlang.org/DIP36" target="_blank">http://wiki.dlang.org/DIP36</a><br>
</blockquote>
<br>
// Does not pretend to be @safe any more<br>
void test2(ref A a) {<br>
}<br>
<br>
I believe 'ref' still *can* be @safe. The unsafe action is really when you assign it to a global pointer.<br>
<br>
void test2(ref A a) {<br>
static A* p;<br>
p = &a; // <-- This is really the only unsafe thing<br>
}<br>
<br>
I think for convenience the function must only be considered unsafe if it does the above. Even returning the 'ref' is @safe so long as the *caller* keeps track of what it passes in, according to DIP25.<br>
<br>
"Following limitation apply to scope ref function parameters (including in ref):<br>
...3. Parameter can only be used as an argument for other function if it also accepts scope ref, no implicit casting away."<br>
<br>
The DIP fails to mention that 'scope' by itself implies 'ref', and (presumably) can be reserved for cases where the caller specifically does not want to allow rvalue temps. 'scope' implies 'ref' because value types are inherently @safe and need no attributes. I'm not sure what's so bad about allowing 'scope ref' arguments to be passed to 'scope' parameters also. It passes the ref it receives, but since it's still 'scope', it's not going anywhere.<br>
<br>
Also, given that 'scope' implies 'ref', there may be significant advantage in simply allowing *all* scope parameters to accept rvalue temps. It would be helpful to have a use case where 'scope' was clearly desired but rvalue temps clearly *not* desired. In most cases, it seems, anything marked 'scope' could easily accept an rvalue temp no problem.<br>
<br>
The 'scope ref' syntax does have a slight conflict with DIP25 and my suggested addition DIP35, in that if other means are found to making returning 'ref' safe, 'scope ref' as a syntax means that no rvalue temporary can ever be returned. Since this may be perfectly acceptable from a 'bad practices' point of view, 'scope ref' may still be a good syntax. But if it were seen as okay to return even a an rvalue temporary, since it is made safe by other means, 'scope ref' would either not be usable for this or would actually be (confusingly) returnable.<br>
</blockquote></div><br></div></div></div><div class="gmail_extra"><div class="gmail_extra">I think having both 'ref' and 'scope ref' is still reasonable, because:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
1. According to DIP25, escaping ref parameter is always safe. But, for rvalue reference, it allows meaningless code.</div><div class="gmail_extra"><br></div><div class="gmail_extra">// Even if this is allowed, it is safe. BUT will introduce bad practice.</div>
<div class="gmail_extra">ref int foo(scope ref int x) { return x; }</div><div class="gmail_extra"><br></div><div class="gmail_extra">// safe</div><div class="gmail_extra">ref int bar(ref int x) { return x; }</div><div class="gmail_extra">
<br></div><div class="gmail_extra">void test() {</div><div class="gmail_extra"> int x;</div><div class="gmail_extra"> foo(x) = 10; // may useful but...</div><div class="gmail_extra"> foo(1) = 10; // completely useless!</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> bar(x) = 10; // may useful, and</div><div class="gmail_extra"> bar(1) = 10; // disallowed.</div><div class="gmail_extra">}</div><div class="gmail_extra">
<br></div><div class="gmail_extra">2. Certainly 'scope' by itself _can_ imply 'ref'. BUT, currently a function parameter without 'ref' storage class implies having value semantics (== copy).</div>
<div class="gmail_extra">
If we change the 'scope' meaning to 'implicit ref', it will break the consistency.</div></div></div></blockquote><div><br></div><div style>Why are you suggesting changing scope to imply ref? This seems wrong. scope and ref are separate, should remain that way.</div>
<div style>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 style><br></div><div style>struct X { int *p; }</div><div style>int* global;<br></div><div style><br></div><div style>void func(scope X x) // note: is not ref</div><div style>{</div><div style> global = x.p; // <- error! scope prevents any part of x escaping, even though it's a copy.<br>
</div><div style>}</div><div style><br></div><div style>This way, scope has meaning with or without ref.</div><div style><br></div><div><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_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 style>What does scope mean in this case? Is this a conflict in some way?</div></div></div></div>