<div dir="ltr">On 24 April 2013 03:33, 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/23/13 12:04 PM, Manu wrote:<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"><div class="im">
On 24 April 2013 00:24, Andrei Alexandrescu<br></div>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a> <mailto:<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>>><div class="im">
<br>
wrote:<br>
<br>
<br>
The very point of this DIP is to not create<br>
syntax-driven features, instead better define existing ones that<br>
make<br>
sense on their own so they can be used for same purpose.<br>
<br>
<br>
It's a new feature, no two ways about it. It overlaps ref and auto<br>
ref without any palpable benefit and defines yet another way to<br>
achieve the same thing as auto ref. On this ground alone the<br>
proposal has a large problem.<br>
<br>
<br></div><div class="im">
How does it overlap ref? It simply justifies the argument with an extra<br>
constraint and isn't tied to 'ref' at all, it's just useful in conjunction.<br>
</div></blockquote>
<br>
The best setup would be:<br>
<br>
1. To take lvalues by reference, write "ref".<br>
<br>
2. To take lvalues and rvalues by reference, write "auto ref".<br></blockquote><div><br></div><div style>That's not a good setup at all. It still doesn't make sense.</div><div style>There's nothing 'automatic' about it, I've specified ref, it is ref, there's no other choice.</div>
<div style>And it relies on a major breaking change to ref, which restricts the functionality of ref by default.</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">
Everything else is superfluous and puts the burden of justification on the proposer. With DIP36, the setup would be:<br>
<br>
1. To take lvalues by reference, write "ref".<br>
<br>
2. To take lvalues and rvalues by reference:<br>
<br>
2.1. Is it a template? Then write "auto ref".<br>
<br>
2.2. Is it a non-template? Then write "scope ref".</blockquote><div style><br></div><div style>Stop talking about r-values, rather, consider safety of passing temporaries. This problem has nothing to do with r-values, this is equally unsafe:</div>
<div style> void f(ref int x);</div><div style> int x;</div><div style> f(x);</div><div style><br></div><div style>It's precisely the same problem, and should be fixed with the same solution.</div><div style><br></div>
<div style>I would rewrite your list as such:</div><div style><br></div><div style>1. 'un-safely' pass a value (may not be a local), write 'ref'</div><div style>2. safely pass a value (may be a local), write 'scope ref'</div>
<div style>3. if you are concerned with templates do you:</div><div style>3.a. want unsafe auto-ref, type 'auto ref' (only non-locals would generate 'ref')</div><div style>3.b. want safe auto-ref, type 'scope auto ref'</div>
<div style><br></div><div style>The automatic selection of ref for templates is fairly unrelated to this issue.</div><div><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">
<div class="im">
<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">
I can't agree that it overlaps auto-ref at all. They're fundamentally<br>
different concepts. auto-ref is a template concept; it selects the<br>
ref-ness based on the received arg. 'auto ref', ie, 'automatic<br>
ref-ness'. It makes no sense on a non-template situation.<br>
I'm still completely amazed that the very reason this DIP makes perfect<br>
sense to me(/us) is the same reason you have a problem with it.<br>
</blockquote>
<br></div>
I don't know how to respond to this. To me is it painfully obvious DIP 36 is poor language design and fails to solve a variety of issues, such as clarifying lifetime of temporaries, safety, and returning ref from functions.<br>
</blockquote><div><br></div><div style>Lifetime of temporaries is the most basic of principles. A local lives the life of the function in which it is defined.</div><div style>Safety is the whole point, and intrinsic to the proposal; safety by explicit specification, thus the programmer retains the option.</div>
<div style><br></div><div style>If a function receives 'scope ref', and wants to return it, I think it should also return 'scope ref' (I guess this wasn't defined in the DIP), otherwise it would be considered an escape.</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">
<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">
2. The proposal is sketchy and does not give many details,<br>
such as the<br>
lifetime of temporaries bound to scope ref objects.<br>
<br>
<br>
It can't because lifetime of temporaries is not defined in D at<br>
all and<br>
suck stuff needs to be consistent. It is not really different from a<br>
lifetime of struct literal temporary used for pass-by-value.<br>
<br>
<br>
A proposal aimed at binding rvalues to references must address<br>
lifetime of temporaries as a central concern.<br>
<br>
<br></div><div class="im">
It's not an r-value, it's a standard stack-allocated temporary. It's<br>
lifetime is identical to any other local.<br>
The reason it's not detailed in the proposal is because it adds no such<br>
new feature, and makes no changes. The lifetime of a local is well<br>
understood.<br>
</div></blockquote>
<br>
Currently rvalues are destroyed immediately after the call they are passed into. DIP 36 would need to change that, but fails to specify it.<br></blockquote><div><br></div><div style>Again, I think it was presumed (I can't conceive any other approach), and certainly Kenji read it that way, because his code appears to do just that.</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">
<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">
3. The relationship with auto ref is insufficiently<br>
described, e.g.<br>
there should be clarification on why auto ref cannot be<br>
improved to<br>
fulfill the desired role.<br>
<br>
<br>
auto ref is a template-world entity. If by "improved" you mean<br>
"completely reworked" than sure, I can add this rationale. Will<br>
do today.<br>
<br>
<br>
I think we should focus on<br></div>
<a href="http://d.puremagic.com/issues/__show_bug.cgi?id=9238" target="_blank">http://d.puremagic.com/issues/<u></u>__show_bug.cgi?id=9238</a><div class="im"><br>
<<a href="http://d.puremagic.com/issues/show_bug.cgi?id=9238" target="_blank">http://d.puremagic.com/<u></u>issues/show_bug.cgi?id=9238</a>> and on making<br>
ref safe.<br>
<br>
<br></div><div class="im">
I don't believe it's possible to make ref safe. Can you suggest any<br>
vision for this?<br>
</div></blockquote>
<br>
<a href="http://d.puremagic.com/issues/show_bug.cgi?id=9238" target="_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=9238</a><div class="im"><br>
<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">
It's unsafe by definition... you are passing a pointer of unknown origin<br>
to a function that could do anything with that pointer.<br>
Hence 'scope ref', which appropriately restricts what the callee is able<br>
to do with it.<br>
</blockquote>
<br></div>
Our intent is to make "ref" always scoped and reserve non-scoped uses to pointers. We consider this good language design: we have unrestricted pointers for code that doesn't care much about safety, and we have "ref" which is almost as powerful but sacrifices a teeny bit of that power for the sake of guaranteed safety. Safety is guaranteed by making sure "ref" is always scoped (references can be passed down but never escape their bound value).<br>
</blockquote><div><br></div><div>That's a massive breaking change...</div><div><br></div><div style>[response in other thread, we need to stop repeating in 2 threads I think]</div><div style><br></div></div></div></div>