<div dir="ltr">On 22 April 2013 03:39, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</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 04/21/2013 02:51 AM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 21 April 2013 06:51, Timon Gehr <<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a><br></div><div><div class="h5">
<mailto:<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a>>> wrote:<br>
<br>
    On 04/20/2013 05:56 PM, Dicebot wrote:<br>
<br>
        You miss quite an important point - DIP36 does not add new<br>
        feature. It<br>
        partially defines existing feature (scope) to replace an<br>
        existing but<br>
        broken solution (auto ref). Nothing new is really added to the<br>
        language,<br>
        only existing stuff better defined.<br>
<br>
<br>
    _New meaning_ is assigned to existing grammar whose original purpose<br>
    is at most loosely related to the _new_ features.<br>
<br>
    I do not think that making 'scope' indicate an rvalue reference is<br>
    particularly future proof.<br>
<br>
<br></div></div><div class="im">
That's not what scope does. Scope promises that the variables will not<br>
escape the scope.<br>
</div></blockquote>
<br>
That is the intention, but this formulation is awfully imprecise. Hence nothing has been implemented.<br>
<br>
void foo(scope ref int x){ ... }<br>
void foo(scope int* x){ ... }<br>
void foo(scope ref int* x){ ... }<br></blockquote><div><br></div><div style>What's the problem here?</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">

// ???<br>
<br>
struct S{<br>
    scope S* x; // ???<br>
}<br></blockquote><div><br></div><div style>I don't think scope on a struct member makes a lot of sense.</div><div style>scope on a local variable declaration makes sense though, it would be able to be assigned from another scope variable.</div>
<div style>Although I would say the same about ref on a local variable declaration, which is disallowed for completely unknown reasons.</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">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
And as such, just happens to make passing a temporary<br>
by ref safe.<br></div>
...<br>
</blockquote>
<br>
But this is not about safety! Passing an rvalue by ref is disallowed even in @system code. Hence 'scope' is assigned a meaning different from its intention. The DIP also aims to add more special behaviour to built-in literals.<br>

</blockquote></div><br></div><div class="gmail_extra" style>Passing an r-value by ref is disallowed for arbitrary reasons. It can easily create a temporary on the spot, but it doesn't, because it's not considered good form to pass a temp to a function by ref.</div>
<div class="gmail_extra" style>This offers the possibility to pass a temp safely, and consequently, the compiler may generate the temp for you.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Explain to me what meaning 'scope' has been assigned that is different from it's intention? And what 'special behaviour'?</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>I honestly can't understand the objections, by you or deadalnix. Can someone actually explain the problem clearly?</div>
</div>