<div dir="ltr">On 27 April 2013 21:11, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 4/27/13 2:37 AM, Manu wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
scope ref T func(scope ref T t) { return t; }<br>
<br>
I think this solves the problem.<br>
</blockquote>
<br></div>
Consider:<div class="im"><br>
scope ref T func(scope ref T t) { return t; }<br></div>
scope ref T func2() { T t; return func(t); }<br></blockquote><div style><br></div><div style>How does auto-ref address this problem?</div><div style><br></div><div style>I think the solution (and I think you proposed this yourself), is that it must assume the lifetime of the returned ref to be the same as the argument with the shortest life, since it can't know which argument was returned, and it would need to be conservative.</div>
<div style>In this case, it knows the lifetime of the argument 't', and that it's a local. Since it is the shortest life argument, it can't return it from func2(), because it knows the returned ref could be(/is, in this case) the local supplied.</div>
<div style><br></div><div style>In the event the function was inlined, maybe there is opportunity to lift this restriction, since it can know which argument was returned.<br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Would be great if you went through all of the existing work on this. Well after you're done preparing your DConf talks :o).</blockquote><div><br></div><div style>I've read the bug where you made your proposals and associated threads. I think you actually proposed this same solution iirc?</div>
<div style>I'm only adding to it that it makes sense for 'scope' to be present, otherwise you eliminate other useful cases where you may want to return an arbitrary ref that's not an argument at all.</div>
<div style>The rule detailed above should only apply to scope-ref, since it's the only case that could possibly deal with short-lived temporaries anyway.</div><div style>If scope ref were implemented in this way, it could receive temp's of r-values, and safely receive locals. I would then disallow passing local variables to non-scope-ref args, as this remains fundamentally unsafe, as it is now.</div>
<div style>vanilla 'ref' becomes useful for receiving and returning unrestricted references, but we gain the confidence that it can't deal with short-lived stack variables, which solves the problem we have now.</div>
<div style><br></div><div style>The only issue I've seen raised that I'm not sure of a good solution for is the one walter raised of conditionally executed statements. But I don't think that's addressed by any of the designs discussed.</div>
<div style>I haven't thought about that yet, but I'm sure a solution exists. I suspect it will have something to do with splitting the statement containing conditions into non-conditional sub-statements, and treating lifetimes normally within the sub-statements...</div>
<div style><br></div><div style>On a side note, my second talk is almost done. Huzzah! I have slides... it's a bit rough, but it's good enough for jazz. And it's a long flight...</div></div></div></div>