<div dir="ltr">On 24 April 2013 00:30, 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 10:05 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">
I can't see the fault in DIP36's reasoning. It just makes sense. Why is<br>
everyone so against it? I'm yet to understand a reason...<br>
</blockquote>
<br></div>
1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.<br></blockquote><div><br>
</div><div style>I see it in exactly the opposite way.</div><div style>This does put an existing feature in good order, ie, scope, which is defined but barely implemented, and might as well have been invented for this purpose as far as I can tell from what little information is available about it.</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">
2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects.<br></blockquote><div><br></div><div style>Is that the only detail missing? An r-value passed this way produces a temp, which is a stack variable. It's life is identical to any other stack variable, ie, it lives for the life of the function where it appears.</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">
3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role.<br></blockquote><div><br></div><div style>auto-ref is a template concept (necessary because ref is not part of the type like in c++). It doesn't make sense to me at all being forced into this concept. I see people saying it over and over, but I just can't see it.</div>
<div style>How does 'auto' apply conceptually? It's a template concept by definition. It feels like auto-ref is deliberately contriving a concept to fit a problem, not DIP36.</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">

4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient.</blockquote><div><br></div><div>
Again, I can't see how this is a new feature at all. It's precisely what you say; making an existing feature (scope) that already exists and is defined actually work, and elegantly solve the problem.</div><div>auto-ref on the other hand IS a new feature (in this context), and it also makes no sense if you ask me. It's a template concept which is not applicable here.</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"> In particular we are much more inclined to impart real, demonstrable safety to "ref"</blockquote>
<div><br></div><div>ref is unsafe by definition. I don't believe this is possible without some further justification.</div><div>DIP36 however creates a situation where it's known that passing a temp is actually safe.</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"> and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.</blockquote>
<div><br></div><div style>What does it mean to make a reference bind to r-values aswell as l-values? Lots of people keep saying this too, but it doesn't really make sense to me either.</div><div style>No reference can bind to r-values, r-values can not be addressed. It's really a temp copy of said r-value that we're dealing with, which is an l-value, ie, a local with a lifetime that's unsuitable for passing by non-scope-ref.</div>
<div style>scope-ref would promise that it won't escape the callee, and thus is safe to pass a temp.</div><div style><br></div><div style>ref is fundamentally broken in D right now. DIP36 creates a situation where it could be fixed. I would personally take DIP36 one step further, and ban all local's from being passed to non-scope ref.</div>
<div style>Yes, a breaking change, but you could argue that any code that passes a stack variable to any ref arg is already broken. But this can be addressed in a future DIP.</div><div style><br></div><div style><br></div>
<div style>...perhaps I'm missing something fundamental in DIP36, or about 'auto ref'?</div><div style>I can't understand why there seem to be 2 polarised parties on this issue, which appear to see the problem completely differently, and can't visualise the counter perspective at all.</div>
</div></div></div>