<div dir="ltr">On 10 May 2013 10:31, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</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 Friday, May 10, 2013 10:08:37 Manu wrote:<br>
> Correct, it specifies something _entirely different_, it says "I can safely<br>
> receive a temporary, because I promise not to escape it". This is the<br>
> actual problem that we're trying to solve, and it addresses the problem<br>
> head on.<br>
><br>
> As I've had to re-iterate countless times, and such is the massive fallacy<br>
> behind all of these threads, this whole debate is NOT about<br>
> lvalues/rvalues, and I wish people would stop using the term 'rvalue' in<br>
> their posts, I worry that they misunderstand the problem every time it's<br>
> said.<br>
><br>
> This code is broken:<br>
> void f(ref int x) {}<br>
> int x;<br>
> f(x);<br>
><br>
> x is an lvalue.<br>
> This is the real problem case, and addressing this will solve the rvalue<br>
> case at the same time.<br>
> Passing an rvalue to a function just generates an implicit temp which is<br>
> functionally identical to the above, except the lifetime of a temp is<br>
> usually the life of the statement rather than the outer scope.<br>
> The problem we need to solve is that of a function being able to safely<br>
> receive a _temporary_.<br>
<br>
</div>The runtime check for ref that we agreed on already solves the @safety<br>
problem. So, I see no point in discussing the @safety problem further unless<br>
there's something wrong with the runtime check solution. And yes, the @safety<br>
problem is not just a question of rvalues. But whether ref should accept<br>
rvalues is very important with regards to being able to write and understand<br>
correct and maintainable code.<br>
<br>
The question of accepting rvalues that we are therefore discussing has<br>
_nothing_ to do with @safety. It's entirely a question of avoiding other types<br>
of bugs - like accepting nonsense like swap(5, 7), which in that case is<br>
fortunately obvious but is not obvious in the general case. IMHO, it needs to<br>
be clear when a function intends to take an argument by ref because it intends<br>
to mutate the argument and when it intends to take an argument by ref because<br>
it wants the efficiency boost of avoiding the copy. In the first case, it makes<br>
no sense to accept rvalues, and in the second case, you definitely want to<br>
accept rvalues. As such, having different syntax is needed (be it auto ref or<br>
@acceptrvalue or whatever).<br>
<br>
I'm not entirely against adding a new attribute for that (it would have the<br>
added benefit of not needing a compiler optimization to guarantee that a<br>
templated function takes its argument by ref when passed an rvalue), but<br>
Walter and Andrei don't want to add new attributes if they can avoid it, so I<br>
don't expect them to be okay with adding a new attribute. And since auto ref<br>
was originally supposed to be this attribute, I'd _much_ rather have that do<br>
it than make the mistake of letting ref accept rvalues.<br></blockquote><div><br></div><div style>What were the arguments again against ref const()? You're talking about making it clear that the function isn't planning on mutating the given rvalue...</div>
<div style>I understand that const is stronger than C++, but is it actually a deal-breaker? It's the most logical fit here.</div></div></div></div>