<div dir="ltr">On 24 April 2013 03:15, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 4/23/13 11:27 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 24 April 2013 00:30, 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>
On 4/23/13 10:05 AM, Manu wrote:<br>
<br>
I can't see the fault in DIP36's reasoning. It just makes sense.<br>
Why is<br>
everyone so against it? I'm yet to understand a reason...<br>
<br>
<br>
1. It defines a new language feature instead of improving the<br>
existing ones. At this point in the development of the language, our<br>
preference should be putting the existing features in good order.<br>
<br>
<br></div><div class="im">
I see it in exactly the opposite way.<br>
This does put an existing feature in good order, ie, scope, which is<br>
defined but barely implemented, and might as well have been invented for<br>
this purpose as far as I can tell from what little information is<br>
available about it.<br>
</div></blockquote>
<br>
"scope" is a keyword, not a language feature. In case you are referring to scope variables, the feature "scope ref" has little to do with it.<br></blockquote><div><br></div><div style>How so? 'scope' simply promises that a variable may not escape its scope, no?</div>
<div style>I think it's important to recognise it as 'scope' + 'ref', the 2 don't have any special meaning when put together, just the logical compound, which allows for a safe situation for temporaries that wasn't previously available.</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">
2. The proposal is sketchy and does not give many details, such as<br>
the lifetime of temporaries bound to scope ref objects.<br>
<br>
<br></div><div class="im">
Is that the only detail missing?<br>
</div></blockquote>
<br>
Many details are missing. This is not a simple problem.<br></blockquote><div><br></div><div style>So what are some others?</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">
An r-value passed this way produces a<br></div>
temp, which is a stack variable. It's life is identical to any other<div class="im"><br>
stack variable, ie, it lives for the life of the function where it appears.<br>
</div></blockquote>
<br>
That's a possibility, but it's a departure from current semantics and is not mentioned in the DIP.<br></blockquote><div><br></div><div style>I think it's presumed in the DIP, and it's certainly how Kenji implemented it.</div>
<div style>What 'current' semantic is it a departure from? The one where passing a literal produces a compile error? Certainly, that's the point.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
auto-ref on the other hand IS a new feature (in this context), and it<br>
also makes no sense if you ask me. It's a template concept which is not<br>
applicable here.<br>
</blockquote>
<br></div>
It is a feature that has been implemented and works, just not in all cases.<br></blockquote><div><br></div><div style>This isn't a 'case'. It's a separate issue.</div><div style>Safely passing a temp to a ref function arg, and whether a template argument is automatically determined to be ref or not are barely related problems.</div>
<div style>I still can't see how auto-ref has any business in this context.</div><div style><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">
In particular we are much more inclined to impart real, demonstrable<br>
safety to "ref"<br>
<br>
<br></div><div class="im">
ref is unsafe by definition.<br>
</div></blockquote>
<br>
We want to aim at making ref safe, thus making it useful as restricted pass-down pointers. For full possibilities, one should use pointers.</blockquote><div><br></div><div style>Okay, I'm good with that too, but how is that intended to work?</div>
<div style>If the intent is to make ref escaping disallowed by default, that is a major breaking change...</div><div style>Can we start talking about virtual-by-default again while we're at it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't believe this is possible without<br>
some further justification.<br>
</blockquote>
<br></div>
The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). It would be very powerful to be able to guarantee that safe code can use ref.<br></blockquote><div><br></div><div style>
Again, this sounds like a major breaking change.</div><div style>Why is scope-ref inferior? It's more informative, and offers more flexibility (ie, the option of ref with or without scope)</div><div style><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">
DIP36 however creates a situation where it's known that passing a temp<br>
is actually safe.<br>
<br></div><div class="im">
and to make "auto ref" work as a reference that can bind to rvalues<br>
as well as lvalues.<br>
<br>
<br></div><div class="im">
What does it mean to make a reference bind to r-values aswell as<br>
l-values? Lots of people keep saying this too, but it doesn't really<br>
make sense to me either.<br>
</div></blockquote>
<br>
I don't understand the question as the answer is in it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No reference can bind to r-values, r-values can not be addressed.<br>
</blockquote>
<br></div>
But auto ref and scope ref do bind to r-values.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's<br>
really a temp copy of said r-value that we're dealing with, which is an<br>
l-value, ie, a local with a lifetime that's unsuitable for passing by<br>
non-scope-ref.<br>
scope-ref would promise that it won't escape the callee, and thus is<br>
safe to pass a temp.<br>
</blockquote>
<br></div>
Our aim is to have ref make that promise.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ref is fundamentally broken in D right now. DIP36 creates a situation<br>
where it could be fixed.<br>
</blockquote>
<br></div>
A new feature is not a fix.</blockquote><div><br></div><div style>If scope is a new feature, then the keyword shouldn't compile and pretend that it does stuff.</div><div style>It's an incomplete/unimplemented feature, not a new one.</div>
<div style>People are aware of it, they can write code that presumes it's present and working. It compiles successfully.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would personally take DIP36 one step further,<br>
and ban all local's from being passed to non-scope ref.<br>
Yes, a breaking change, but you could argue that any code that passes a<br>
stack variable to any ref arg is already broken. But this can be<br>
addressed in a future DIP.<br>
<br>
<br>
...perhaps I'm missing something fundamental in DIP36, or about 'auto ref'?<br>
I can't understand why there seem to be 2 polarised parties on this<br>
issue, which appear to see the problem completely differently, and can't<br>
visualise the counter perspective at all.<br>
</blockquote>
<br></div>
DIP36 should be closed. We must focus on making ref safe and on making auto ref work with non-templates.</blockquote><div><br></div><div style>I'm fine with that, but it sounds like a massive breaking change.</div><div style>
However upon the presumption of this new goal, I don't see the relevance of auto-ref anymore? Why continue to bring it up?</div><div style>If ref is safe, nothing else is needed.</div></div></div></div>